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Abstract 

With  the  expanding  number  of  components  provided  on  a  single  digital  chip,  verifi¬ 
cation  of  digital  designs  is  becoming  a  major  problem.  The  more  circuits  one  places  on  a 
single  chip,  the  greater  the  number  of  input/ouput  combinations  which  need  to  be  checked. 
A  paper  by  Barrow  in  1984  discusses  a  Prolog-based  hierarchical  formal  verification  system 
which  he  calls  VERIFY.  Barrow  provides  information  on  what  VERIFY  can  and  cannot 
do,  and  on  projected  enhancements.  He  does  not,  however,  mention  how  VERIFY  actu¬ 
ally  performs  the  task  of  formal  verification.  This  thesis  will  provide  a  description  of  one 
possible  implementation  of  the  formal  verification  methodology  described  in  VERIFY. 
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A  PROLOG-BASED  SYSTEM  FOR 
HARDWARE  VERIFICATION 


I.  Introduction 


1.1  Background 

In  any  design  environment,  the  designer  would  like  to  know  if  his  design  really  works 
as  expected.  Did  he  build  the  product  right?  With  the  expanding  number  of  components 
provided  on  a  single  digital  chip,  verification  of  digital  designs  is  becoming  a  major  problem. 
The  more  circuits  one  places  on  a  single  chip,  the  greater  the  number  of  input/ouput 
combinations  which  need  to  be  checked. 

In  the  Air  Force  Instititute  of  Technology  (AFIT)  School  of  Engineering,  there  is  a 
group  of  students  whose  educational  emphasis  is  on  the  design  of  these  Very  Large  Scale 
Integrated  (VLSI)  circuits.  These  students  would  like  to  have  better  methods  of  ensuring 
that  a  design  is  correct  before  it  is  sent  to  another  agency  for  fabrication.  A  paper  by 
Barrow  (l)in  1984  discusses  a  Prolog-based  verification  system  which  he  calls  VERIFY. 
Barrow  provides  information  on  what  VERIFY  can  and  cannot  do,  and  on  projected 
enhancements.  He  did  not,  however,  mention  how  VERIFY  actually  performs  the  task  of 
formal  verification.  This  thesis  will  provide  a  description  of  one  possible  implementation  of 
the  concepts  in  VERIFY.  Once  a  Prolog  verification  methodology  is  provided,  the  resulting 
system  could  be  integrated  into  a  larger  hardware  design  system  for  use  by  the  AFIT 
VLSI  group.  A  VLSI  design  system  containing  verification  tools  will  speed  up  the  design- 
fabrication  cycle  and  ultimately  result  in  both  time  and  cost  savings  to  AFIT. 

1.2  Problem 

In  this  thesis,  hierarchical  formal  verification  methods  will  be  applied  to  the  prob¬ 
lem  of  verification  of  digital  circuit  designs.  Formal  verification  methods  attempt  to  prove 
that  a  circuit’s  structural  description  implies  a  specified  behavioral  description.  A  circuit’s 
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structural  description  is  obtained  through  some  synthesis  process.  At  some  lower  level  (i.e., 
gate,  transistor)  the  behavior  and  structure  are  equivalent,  forming  the  basis  for  deriving 
behavior  at  higher  levels.  A  high-level  behavioral  description  can  thus  be  inferred  from  a 
circuit’s  structure.  The  approach  in  this  thesis  will  be  to  derive  a  behavioral  description 
by  combining  previously  verified  modules  hierarchically.  Barrow’s  methodology  requires 
each  module  to  be  primitive  or  composed  of  other  modules.  A  primitive  module  is  a  low- 
level  module  where  behavior  and  structure  are  the  same.  The  module  is  described  only 
in  a  black-box  sense  of  inputs,  outputs,  and  specified  behavior.  Since  a  primitive  mod¬ 
ule’s  behavior  and  structure  are  equivalent,  structure  implies  behavior,  and  all  primitive 
modules  are  verified.  All  other  modules  are  composed  of  primitive  modules  and  other 
higher  level  modules.  The  non-primitive  modules  must  fully  specify  their  structure  and 
expected  high-level  behavior.  All  non-primitive  modules  are  verified  by  first  verifying  the 
module’s  components.  If  all  components  are  successfully  verified,  then  the  behaviors  de¬ 
rived  during  the  component’s  verifications  can  be  substituted  for  those  components  while 
deriving  the  module’s  behavior.  Assuming  this  behavioral  derivation  process  produces  a 
valid  behavioral  description,  this  derived  behavioral  description  is  now  compared  to  the 
module’s  specified  behavioral  description.  Barrow  elects  to  show  that  the  derived  behavior 
and  specified  behavior  are  equivalent.  If  the  behaviors  are  equivalent,  it  is  also  true  that 
structure,  the  derived  behavior,  implies  behavior,  the  specified  behavior. 

This  thesis  advocates  a  specific  method  of  verification  of  digital  hardware  design. 
To  understand  the  specific  problem,  a  general  understanding  of  digital  design  verification 
techniques  is  required. 

1.3  Summary  of  Current  Knowledge 

Approaches  to  Verification.  The  process  of  ensuring  a  digital  circuit  conforms  to 
its  specification  can  be  approached  in  three  different  ways:  formal  synthesis,  simulation, 
and  formal  verification.  Formal  synthesis  is  a  design  methodology  which  ensures  that  the 
resulting  implementation  performs  the  high-level  specified  behavior.  Such  a  process  would 
take  a  high-level  behavioral  description  and  automatically  generate  the  proper  implemen¬ 
tation.  Formal  synthesis  currently  remains  a  lofty  and  unattainable  goal.  Simulation  tries 
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to  ensure  that  the  design  meets  the  expected  behavior,  also  known  as  the  functional  or 
behavioral  specification,  by  applying  an  appropriate  number  of  inputs  and  “verifying”  that 
they  produce  the  expected  outputs.  Most  “verification”  efforts  to  date  use  some  form  of 
simulation  and  do  not  fully  verify  a  circuit’s  behavior.  Maruyama  contends  that  the  prob¬ 
lem  with  simulation  is  that  it  “does  not  definitely  ensure  the  conformance  of  design  to 
specifications”  (12:22).  This  is  the  reason  formal  synthesis  or  formal  verification  must  be 
considered.  Formal  verification  uses  logic  to  verify  a  circuit.  Each  circuit  to  be  verified  will 
consist  of  some  high-level  behavioral  specification  and  some  technology-dependent  phys¬ 
ical  implementation.  Formal  verification  verifies  a  circuit  by  showing  that  the  physical 
implementation,  or  structure,  implies  the  high-level  specification,  or  behavior.  In  logic,  it 
establishes  that 


Structure  =>  Behavior. 

There  are  two  basic  ways  to  prove  that  this  implication  is  valid.  The  first  method  is  to 
use  predicate  logic  to  perform  a  step-by-step  formal  proof  of  this  implication.  The  second 
method,  which  is  used  by  Barrow,  is  to  logically  determine  that  the  behavior  and  structure 
are  equivalent. 


If  Structure  Behavior  then,  by  definition, 

Structure  =$►  Behavior  and  Behavior  =►  Structure. 

The  systems  used  to  represent  behavior  and  structure  and  the  methods  used  to  prove 
that,  directly  (implication)  or  indirectly  (equivalence),  structure  implies  behavior,  provide 
the  major  differences  between  formal  verification  methodologies.  It  should  be  noted  that 
Barrow’s  VERIFY  could  be  set  up  to  prove  only  that  structure  implies  behavior;  however, 
Barrow  chose  to  use  Prolog  to  implement  his  methodology.  Prolog’s  operation  is  based 
on  pattern-matching,  and  pattern-matching  can,  and  is,  exploited  to  make  equivalence  de¬ 
termination  much  easier  than  implication  proving.  The  equivalence  determination  process 
will  be  explained  in  great  detail  in  the  Program  Development  chapter. 

Formal  Verification  Methodologies.  The  majority  of  formal  verification  research 
appears  to  be  coming  from  the  United  Kingdom,  and,  in  particular,  from  Cambridge 
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University.  Gordon  (8:2)  feels  that  for  formal  verification  to  be  possible  for  real  systems, 
a  verification  system  must  provide  both  a  high-level  mathematical  formalism  for  writing 
specifications,  and  tools  for  mechanizing  the  proof  of  correctness.  Gordon  admits  that 
VERIFY  contains  these  necessary  qualities,  but  he  advocates  the  use  of  predicate  logic  to 
both  specify  and  verify  circuits.  Gordon  uses  a  predicate  logic  system  called  Higher-Order 
Logic,  or  HOL. 

Gordon  has  provided  a  defense  of  the  use  of  HOL  for  formal  verification  (9).  In  that 
discussion,  examples  are  provided  which  show  how  HOL  can  be  used  to  specify  a  circuit’s 
black-box  behavior,  or  specification,  by  imposing  constraints  on  the  inputs  and  outputs. 
Then,  given  one  possible  physical  implementation  of  the  device,  the  physical  implementa¬ 
tion  can  be  represented  logically  by  another  group  of  constraints  on  the  inputs,  outputs, 
and  internal  connections.  The  specifications  and  implementations  provided  by  a  user  are 
expressed  as  a  function  which  is  composed  of  constraints  specified  as  normal  predicate 
logic  statements  consisting  of  quantifiers,  propositions,  and  predicates.  This  representa¬ 
tion  can  be  classified  as  the  “definitional  method”  as  presented  by  Clocksin  (4:63-64), 
except  predicate  logic  constructs  are  used  as  opposed  to  Prolog  syntax.  “To  verify  that 
the  implementation  correctly  implements  the  specification,  it  must  be  proved  that  if  the 
inputs  and  outputs  satisfy  the  constraints  imposed  by  the  implementation,  then  they  also 
satisfy  the  specification”  (9:163).  Notice  that  the  implementation  must  only  imply  the 
specification  and  not  be  strictly  equivalent.  This  may  allow  the  implementation  actually 
to  provide  more  functionality  than  the  specification.  HOL  actually  performs  a  formal  proof 
of  the  implication.  This  implication  is  proven  in  HOL  through  exhaustive  simulation  for 
all  inputs  (this  would  show  equivalence)  in  simple  cases,  by  expansion  of  library  compo¬ 
nent  definitions,  and  even  by  mathematical  induction.  The  process  is  comparable  to  a 
hand-written  formal  proof.  HOL  also  provides  capabilities  for  dealing  with  time  (9:169). 
Barrow’s  VERIFY  provides  no  methods  for  dealing  with  time  or  performing  mathematical 
induction  (1:488-489). 

Barrow’s  modules  allow  circuits  to  be  verified  hierarchically  by  verifying  lower  level 
modules  and  keeping  them  in  a  library  for  use  by  larger  systems.  Using  this  structural 
hierarchy  to  aid  in  design  verification  is  essential  to  achieve  verification  of  circuits  which 
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contain  more  than  basic  elements.  Hwang  (11)  also  uses  hierarchy  to  verify  the  correctness 
of  finite-state  machines.  Hwang  considers  a  module  to  consist  of  an  implementation  part 
and  a  specification  part.  The  specification  is  a  description  of  the  expected  behavior.  The 
implementation  can  be  further  divided  into  the  following  categories: 


1.  Interior  node  module  -  a  module  composed  of  submodules,  each  containing  a  speci¬ 
fication  and  implementation. 

2.  Leaf  node  module  -  a  set  of  net  lists  of  elementary  gates  and  latches  obtained  by 
some  synthesis  process. 

3.  Primitive  module  -  a  module  which  need  not  be  verified,  so  it  can  be  assumed  to 
satisfy  the  specification.  (11:410) 

Hwang  argues  that  most  leaf  nodes  can  be  modelled  as  finite  state  machines  and 
presents  a  method  to  verify  designs  hierarchically.  He  shows  that  a  finite-state  machine 
representation  of  the  implementation  satisfies  the  finite-state  machine  repre.entation  of 
the  specification  if  and  only  if  every  input  sequence  applied  to  a  specific  state  in  both  the 
specification  and  implementation  machines  results  in  the  same  output  sequence  in  both 
the  specification  and  implementation  machines  (11:411). 

The  methodologies  of  Gordon,  and  Hwang  are  viable  alternatives,  but  Barrow’s  VER- 
IF  x  methodology  will  be  explored  in  this  thesis.  HOL  provides  greater  flexibility  in  logic 
specification,  time  representation,  and  proof  mechanisms,  but  requires  a  learning  curve 
which  precludes  a  normal  AFIT  thesis  cycle.  Hwang’s  methodology  is  very  similar  to 
Barrow’s,  but  provided  no  guidance  on  a  possible  implementation.  Barrow’s  VERIFY  is 
implemented  in  Prolog,  which  is  readily  available  at  AFIT,  and  is  the  current  required 
language  for  the  introductory  Artificial  Intelligence  course.  The  apparent  replication  of 
Barron’s  VERIFY  by  Brezocnik  et  al.  (3)  and  Grabowiecki  et  al.  (10)  and  the  informa¬ 
tion  provided  by  these  efforts  added  to  the  viability  of  a  system  such  as  VERIFY. 

One  should  be  cautioned  that  Barrow’s  VERIFY  has  limits.  The  most  critical  lim¬ 
itation  is  the  lack  of  a  method  for  temporal  representation.  Even  given  this  limitation 
many  types  of  circuits  can  be  verified,  and,  in  the  process  of  verifying  those  circuits,  the 
methods  to  provide  temporal  representation  can  be  studied.  This  thesis  provides  a  Prolog 
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implementation  of  Barrow’s  formal  verification  methodology,  and  no  time  will  be  devoted 
to  the  determination  of  a  possible  method  for  temporal  representaion. 

1.4  Approach 

The  AFIT  VLSI  group  currently  “verifies”  module  correctness  through  simulation. 
As  mentioned  above,  simulation  cannot  truly  verify  module  correctness.  Some  method  for 
formal  verification  is  required.  Prolog  enables  a  circuit  to  be  described  behaviorally,  and 
also  provides  predicate-logic  constructs  for  formal  verification.  Also,  Prolog  can  be  devel¬ 
oped  in  a  PC  environment,  which  allows  rapid  prototyping.  Barrow  has  a  nice  methodology, 
but  will  it  really  work  in  practice?  The  need  for  a  formal  verification  system,  Barrow’s 
methodology,  and  the  easy  access  to  Prolog  all  played  a  role  in  the  approach  utilized  in 
this  thesis. 

The  goal  of  this  thesis  was  to  use  Prolog  to  develop  a  prototype  of  Barrow’s  ver¬ 
ification  methodology,  remembering  that  the  ultimate  goal  would  be  to  provide  a  de¬ 
sign/verification  system  to  the  AFIT  VLSI  group.  The  approach  was  to  build  the  pro¬ 
totype  by  first  verifying  a  simple  combinational  logic  circuit  and  then  move  to  the  real 
problem  of  verifying  a  sequential  circuit.  An  Exclusive-OR  gate  was  first  verified  using  a 
Boolean  Expansion  algorithm  created  by  CPT  Dukes  (6:39-43).  Next  Barrow’s  counter¬ 
circuit  example  was  attempted.  This  attempt  proved  successful  and  provided  the  basic 
prototype  structure  to  be  used  for  further  research.  At  that  point,  only  modules  composed 
of  primitive  submodules  could  be  verified.  To  have  a  true  hierarchical  verification  system, 
one  would  need  to  provide  verification  to  any  depth.  It  was  here  that  Barrow’s  exploita¬ 
tion  of  hierarchy  was  discovered.  Barrow  fully  verified  each  submodule  in  the  process  of 
verifying  a  module.  This  required  every  module  to  be  fully  specified  both  behaviorally  and 
structurally.  Once  a  submodule  was  verified,  the  submodule’s  derived  behavior  (and/or 
state)  could  be  substituted  for  the  submodule’s  output  (and/or  next  state)  when  deriv¬ 
ing  a  module’s  behavior.  This  would  make  all  previously  verified  submodules  appear  to 
be  primitive,  since  a  simple  substitution  would  be  made.  A  full-adder  module  containing 
three  levels  of  structure  was  verified  to  show  this  kind  of  hierarchical  verification.  The 
full-adder  verification  required  the  use  of  a  mainframe  version  of  Quintus  Prolog  due  to 
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the  small  memory  model  of  PROLOG- 1.  A  PC  version  of  Quintus  Prolog  will  be  used  in 
future  research. 

Once  it  was  shown  that  a  sequential  circuit  and  a  module  consisting  of  more  than  two 
structural  levels  could  be  formally  verified,  the  work  on  this  thesis  turned  to  an  explanation 
of  just  how  this  was  accomplished.  AFIT  now  has  a  working  prototype  to  build  a  library 
of  formally  verified  circuit  modules. 

1.5  Organization  of  Thesis 

In  the  chapters  to  follow,  the  prototype  developed  to  perform  formal  verification  will 
be  presented.  In  the  rest  of  this  thesis,  the  prototype  will  be  identified  as  AFIT-VERIFY. 
An  introduction  to  Prolog  concepts  is  included  to  demonstrate  the  types  of  constructs 
required  to  use  and  further  develop  AFIT_VERIFY.  The  formal  verification  methodology 
of  Barrow  and  its  implementation,  AFIT-VERIFY,  are  explained  in  detail.  This  discussion 
also  includes  an  example  of  a  module  description  which  is  used  to  verify  a  circuit.  Next, 
the  actual  development  of  AFIT-VERIFY  is  discussed.  The  body  of  the  thesis  concludes 
with  a  summary  of  the  results  and  recommendations  for  further  development.  Appendix 
A  provides  a  listing  of  all  code  developed  for  AFIT-VERIFY,  and  Appendix  B  contains 
some  sample  verification  runs  using  PROLOG-1  and  Quintus  Prolog.  The  sample  runs 
provide  a  flavor  of  the  type  of  processing  required  to  verify  even  small  circuits.  The  runs 
also  contrast  the  capabilities  of  PROLOG- 1  and  Quintus  Prolog. 
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II.  Introduction  to  Prolog 


2.1  Introduction 

To  achieve  a  full  understanding  of  the  subsequent  chapters,  which  discuss  the  imple¬ 
mented  code,  one  must  have  some  basic  understanding  of  Prolog  and  how  it  works.  This 
chapter  will  explain  how  Prolog  differs  from  traditional  languages  such  as  PASCAL,  it 
will  explain  how  a  Prolog  program  is  created,  and  it  will  discuss  the  capabilities  of  Prolog 
which  make  it  appropriate  for  formal  verification. 

Artificial  Intelligence  programmers  should  be  well-versed  in  both  Lisp  and  Prolog 
(2:vii-ix).  Languages  like  PASCAL  are  how-type  or  procedural  programming  languages. 
The  programmer  must  specify  how  a  specific  procedure  is  to  be  accomplished.  Some 
believe  that  Lisp  is  the  “champion”  of  the  how-type  languages.  Prolog,  on  the  other  hand, 
is  a  what-type  or  declarative  language.  In  essence,  one  states  logically  what  needs  to  be 
dene  and  Prolog  does  it.  At  least  it  appears  that  way.  A  note  of  caution  is  due  here. 
“Plentiful  experience  and  devotion  to  conventional  procedural  programming,  for  example 
in  PASCAL,  might  be  an  impediment  to  the  fresh  way  of  thinking  Prolog  requires”(2:xii). 

Prolog,  which  stands  for  PROgramming  in  LOGic,  is  rooted  in  mathematical  logic. 
In  particular,  the  syntax  of  Prolog  is  first-order  predicate  logic  written  in  Horn  clause 
form  (2:61).  A  Horn  clause  is  a  logical  implication  with  no  more  than  a  single  atom  as 
consequent.  For  example: 


A  <=  B\k .  .  .&2?n 

In  this  case,  an  atom  is  meant  to  be  some  indivisible  concept.  The  level  of  indivisibility 
depends  on  the  level  of  abstraction  used  to  describe  a  particular  problem. 

Clocksin  and  Mellish  (5:240-244)  created  a  Prolog  program  to  convert  a  first-order 
predicate  calculus  formula  into  clause  form.  The  clause  form  produced  by  Clocksin  and 
Mellish  is  not  Horn  clause  form,  but  a  mechanical  process  exists  to  convert  the  Clocksin  and 
Mellish  clause  form  into  Horn  clause  form.  This  process  requires  redefining  an  atom  as  the 
negation  of  another  atom.  Then  the  redefined  atom  can  be  moved  across  the  implication. 
For  example,  given  the  following  clause  form, 
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AVB  <=  DkE, 


and  the  fact  that 


C&-B, 

the  resulting  Horn  clause  would  be  the  following: 

A  <=  CkDkE. 

Although  this  mechanical  process  is  nice  to  have,  it  is  generally  not  used.  Most  problem 
statements  can  be  manipulated  and  placed  in  Horn  clause  form.  Using  the  Horn  clause 
form  allows  Prolog  to  mechanically  prove  user-supplied  theorems,  by  using  the  resolution 
principle  introduced  by  Robinson  (13). 

A  complete  understanding  of  mathematical  logic  or  the  theory  behind  resolution  is 
not  required  to  create  some  very  powerful  programs  using  Prolog.  The  basic  mechanisms 
of  Prolog  are  pattern  matching,  tree-based  data  structuring,  and  automatic  backtracking. 
Prolog  is  known  as  a  goal-directed  language.  This  is  “becai'se  Prolog  accepts  questions  as 
goals  that  are  to  be  satisfied”  (2:7).  This  will  be  made  much  clearer  in  the  examples  to 
follow. 

2.2  Prolog  Syntax 

Prolog  has  only  a  single  data  object,  the  term.  A  term  is  either  a  constant,  a  variable, 
or  a  structure.  A  constant  can  be  either  a  number  or  an  atom.  An  atom  is  any  sequence 
of  characters,  except  control  characters,  which  begins  with  a  lower  case  letter.  (Atoms 
beginning  with  an  upper  case  letter  must  be  enclosed  in  single  quotes.)  A  variable  must 
begin  with  an  upper  case  letter  or  the  underline  character.  The  underline  character, 
when  used  alone,  is  known  as  the  anonymous  variable.  The  anonymous  variable  is  used 
when  its  value  is  irrelevant.  It  can  be  thought  of  as  a  “don’t  care”  value.  Examples  of 
atoms  and  variables  appear  in  Table  2.1 

“A  structure  is  composed  of  an  atom,  called  the  principal  functor,  followed  by  a 
sequence  of  terms  called  components  of  the  structure”  (7:2-6).  Structures  are  stored  as 
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Table  2.1.  Prolog  atoms  vs.  variables 


Atoms 

Variables 

a 

an-Atom 

*an_Atom* 

* Prolog- 1* 

A 

Var 

A-variable 

VARi 

trees  with  the  principal  functor  being  the  root  and  the  components  as  the  offspring.  Any 
compoi  ent  which  is  also  a  structure  appears  as  a  subtree  under  the  principal  functor.  For 
example,  the  structure  triangle  (point  (1,1)  ,A,point(2,3)),  which  represents  a  family 
of  triangles  containing  the  points  (1,1), (2, 3),  and  some  unknown  point,  A,  would  be  stored 
as  shown  in  Figure  2.1. 


Figure  2.1.  Triangle  structure  as  seen  by  Prolog. 
The  following  structure, 


parent(tom,bob), 

consists  of  the  principal  functor  parent  and  the  two  components  tom  and  bob  which,  in 
this  case,  happen  to  be  atoms.  The  above  parent  structure  will  be  used  to  explain  how 
one  can  use  Prolog  in  a  declarative  manner  to  solve  problems. 

The  family  relation  problem  is  a  classic  introductory  problem  in  Artificial  Intelligence 
and  especially  in  Prolog.  The  structure  parent  (tom, bob)  means  Tom  is  the  parent  of  Bob 
and,  in  Prolog,  is  called  a  fact.  As  with  other  programming  languages  the  atoms  parent, 
tom,  and  bob  mean  nothing  in  particular  to  Prolog;  the  programmer  provides  the  semantics. 
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Prolog  merely  recognizes  the  pattern  parent  (tom, bob).  One  can  assert  many  such  facts 
to  represent  the  family  tree  in  Figure  2.2. 


Figure  2.2.  Sample  Family  Tree. 


parent(pam,bob) . 
parent (tom, bob) . 
parent(tom.liz) . 
parent (bob , ann) . 
parent (bob, pat) . 
parent (pat, jim) . 

These  facts  would  constitute  a  very  simple  Prolog  program  consisting  of  six  clauses.  After 
loading  the  program  one  could  ask  “Is  Bob  the  parent  of  Pat?”  by  typing  the  question 


?-  parent  (bob, pat) .  (  ?-  is  the  Prolog  prompt) 

Prolog  would  find  this  asserted  fact  and  answer  yes.  One  could  also  ask  “Who  is  the 
parent  of  Bob?”  by  typing  the  question 
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?-  parent (X, bob) . 


Prolog  would  then  answer 


X  ■  pam, 


and,  if  Prolog  is  told  to  provide  more  answers  (“y”  in  Prolog-1  and  in  Quintus  Prolog), 
it  would  reply 


X  «  tom, 

and,  if  more  answers  are  requested,  Prolog  would  reply 


no. 


Granted,  this  may  not  seem  useful  to  a  non-database  programmer.  One  might  think 
that  if  he  has  to  provide  the  program  with  all  the  facts  to  begin  with,  then  he  really  doesn’t 
need  the  program.  It  should  be  noted  that  Prolog  can  be  viewed  as  a  relational  database, 
and  the  programs  written  are  just  queries  to  that  database.  This  view  of  a  program  would 
be  fori. cm  to  most  functional  programmers.  AFIT.VERIFY  was  developed  using  Prolog’s 
declarati*  programming  style.  The  resulting  code  shows  more  resemblance  to  a  standard 
language  than  to  a  database  query  language  due  to  Prolog’s  added  deductive  capabilities 
and  flexible  query  mechanisms. 

Prolog  clauses  come  in  three  varieties:  facts,  rules,  and  questions.  A  Prolog  clause 
consists  of  the  head  and  the  body.  The  head  and  body  are  separated  by  the  :  -  operator. 
For  example: 


offspring(Y,X)  head 

parent(X,Y) .  body 

The  operator  represents  the  implication  arrow,  <=.  So  ,  the  Pruiog  clause  really 
means  that  if  the  body  is  true,  then  the  head  is  true.  The  body  is  a  list  of  goals  separated 
by  commas  (logical  AND)  or  semicolons  (logical  OR),  and  the  head  provides  the  pattern 
to  be  searched  for  by  Prolog.  A  fact  is  something  that  is  always  true,  which  is  represented 
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by  a  clause  with  an  empty  body.  A  question  only  has  the  body,  which  is  represented  by  a 
clause  with  an  empty  head.  A  rule  declares  that  something  (the  head)  is  true  provided  a 
given  condition  (the  body)  is  true  (2:13).  This  can  be  shown  by  Table  2.2  and  the  following 
example. 


Table  2.2.  Prolog  clauses. 


Form 

Type 

H  «= 

<=  T 
H<=T 

fact 

question 

rule 

Given  the  six  previously  defined  parent  facts,  one  could  now  create  a  grandparent 
rule.  A  grandparent  is  a  parent  of  a  parent.  In  Prolog,  all  variables  are  assumed  to  be 
universally  quantified,  so  logically  stated, 

for  all  X  and  Y, 


lie  a  grandparent  of  Y  if 
X  is  a  parent  of  Z  and 
Z  is  a  parent  of  Y. 


This  is  easily  stated  in  Prolog  as: 


grandparent (X,Y) 
parent (X,Z) , 
parent (Z,Y). 


Now,  if  one  asks  the  question  grandparent(X,pat),  Prolog  will  respond  with 


X  *  pam, 


and  then,  if  more  answers  are  required, 


X  =  tom. 
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One  can  see  that  even  though  no  grandparent  facts  exist,  using  the  grandparent  rule 
one  can  derive  all  grandparent-grandchild  relationships  by  using  the  question 

?-  grandparent (X,Y) . 

The  previous  example  is  carried  out  in  much  more  detail  in  Bratko  (2).  Other  rules 
about  families  illustrate  some  subtle  problems.  A  sister  is  a  female  with  the  same  parents 
as  another  sibling.  This  logic  results  in  a  girl’s  being  her  own  sister.  Prolog  looks  as 
if  it  does  so  much  (and  it  does)  that  a  programmer  can  begin  to  believe  that  Prolog  is 
thinking  and  forget  to  think  for  himself.  Prolog  simply  goes  through  the  database  searching 
for  possible  instantiations  of  variables  to  solve  a  user-provided  goal.  The  search  can  be 
speeded  up  by  reducing  the  search  space  through  the  introduction  of  cuts ,  which  allow  a 
goal  to  be  satisfied  only  once  with  the  same  instantiation.  This  is  when  programming  in 
Prolog  gets  dangerous,  because  some  solutions  have  been  eliminated  from  the  search  space. 
The  programmer  is  now  telling  Prolog  how  to  get  a  solution  as  opposed  to  what  solution 
is  needed.  As  much  as  possible,  one  should  use  the  strengths  of  Prolog  and  its  what-type 
capabilities. 

Another  major  feature  of  Prolog,  which  is  necessary  to  tackle  problems  of  any  signif¬ 
icance,  is  recursion.  A  simple  example  of  this  is  the  predecessor  relation  (2:15).  A  parent 

is  a  predecessor.  So  is  a  grandparent,  great-grandparent,  great-great-grandparent, _ A 

predecessor  clause  could  be  defined  as, 


predecessor (X,Y) 

parent (X,Y) . 
predecessor (X,Y) 

parent (X,Z) , 
parent (Z,Y) . 
predecessor (X,Y) 

parent (X,Z) , 
parent (Z, A) , 
parent (A, Y) . 
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and  predecessor  clauses  could  be  added  to  a  sufficient  depth  to  cover  all  cases  in  the  family 
tree.  But  isn't  a  predecessor  more  simply  defined  as  either  a  parent  or  a  predecessor  of  a 
parent?  This  is  easily  written  in  Prolog  as 


predecessor (X,Y) 
parent(X,Y) . 
predecessor(X.Y) 
parent (X,Z) , 
predecessor(Z,Y) . 


This  new  definition  will  cover  predecessors  to  any  depth  and  demonstrates  the  power 
of  Prolog  to  encapsulate  a  large  search  problem  into  a  few  simple  clauses. 

It  should  be  noted  that  multiple  clauses  with  the  same  principal  functor  and  number 
of  components  (arity)  perform  the  logical  OR  function  of  the  clause  bodies.  The  sepa¬ 
rate  goals  of  the  two  clauses  could  appear  in  a  single  predecessor  clause  separated  by  a 
semicolon,  as  follows: 


predecessor (X , Y) 
parent(X.Y) 

> 

(parent (X,Z) , 
predecessor (Z,Y)) . 

However,  the  use  of  separate  clauses  enhances  readability  and  is  the  recommended 
Prolog  programming  practice.  Prolog  merely  searches  for  the  matching  clause  when  trying 
to  satisfy  a  goal.  If  the  first  clause  fails,  Prolog  just  moves  to  the  next  matching  clause. 
This  also  brings  up  the  point  that  ordering  of  clauses  plays  a  role  in  the  efficiency  of  the 
search.  The  clauses  which  will  be  satisfied  most  frequently  in  a  program  should  be  placed 
at  the  top  of  the  database  (i.e.,  should  occur  first  in  the  program). 
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2.3  Summary 

Although  these  examples  are  simple,  they  do  provide  the  basis  for  an  understanding 
of  Prolog.  The  most  important  concepts  to  grasp  are  that  rules  are  simply  stated  as,  “This 
pattern  holds  if  the  following  goals  can  be  proven”.  Since  the  ultimate  goal  of  this  research 
is  to  verify  large  circuits  hierarchically,  extensive  use  of  recursion  will  be  required  in  the 
development  of  the  system  described  in  this  thesis. 

The  final  point  to  make  about  Prolog  concerns  modification.  In  the  chapters  to  follow, 
the  code  should  be  explained  in  sufficient  detail  to  allow  modification  without  requiring  a 
major  revision.  Generally,  to  handle  a  new  case,  one  just  adds  another  clause.  This  is  quite 
acceptable,  and  this  type  of  programming  lends  itself  to  follow-on  efforts.  An  interested 
person  can  take  the  code  developed  in  this  effort  and  simply  add  new  clauses  to  cover  the 
types  of  designs  of  interest  to  future  research. 

This  chapter  was  not  intended  to  provide  a  thorough  tutorial  on  Prolog,  but  simply 
to  allow  the  reader  to  understand  the  basic  concepts.  The  use  of  cuts  and  ordering  of 
clauses  are  explained  in  some  detail  in  the  references  (2,  7).  As  with  most  languages,  the 
best  way  to  get  an  understanding  of  Prolog  is  just  to  write  some  programs. 
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III.  VERIFY 


3.1  Introduction 

The  thrust  of  this  thesis  is  to  provide  a  Prolog  implementation  of  the  formal  ver¬ 
ification  methodology  described  by  Barrow  (1).  Barrow  developed  a  program  in  Prolog 
called  VERIFY  which  tries  to  prove  the  correctness  of  digital  designs  (1:437).  The  key 
principle  underlying  VERIFY  is  that,  “given  the  behaviors  of  components  of  a  system  and 
their  interconnections,  it  is  possible  to  derive  a  description  of  the  whole  system”  (1:445). 
His  program  is  based  on  the  assumption  that  a  design  is  “comprised  of  modules,  organized 
hierarchically,  and  modeled  as  finite  state  machines”(l:440).  The  modules  are  described 
by  stating  the  inputs,  the  expected  outputs,  and  any  internal  state  information  (1:440). 
These  statements  make  up  a  structural  description.  VERIFY  takes  the  information  in  the 
structural  description  and  derives  a  behavioral  description  (1:450).  Using  the  inherent  pat¬ 
tern  matching  capabilities  of  Prolog  and  some  added  mathematical  techniques,  VERIFY 
then  tries  to  prove  the  equivalence  of  the  derived  behavioral  description  and  the  speci¬ 
fied  behavioral  description.  The  mathematical  techniques  include  methods  for  algebraic 
manipulation,  simplification,  canonicalization  (i.e.,  putting  equations  in  a  normal  form  for 
easier  comparison),  evaluation,  and  case  analysis  (1:452-454).  If  the  derived  behavioral 
description  and  the  specified  behavioral  description  can  be  proved  to  be  equivalent,  then 
the  module  specification  is  verified;  however,  there  is  still  the  possibility  that  the  original 
module  specification  is  incorrect.  That  is  a  completely  different  problem  which  Barrow 
doesn’t  attempt  to  address  (1:445). 

Brezocnik  et  al.  (3)  and  Grabowiecki  et  al.  (10)  have  reported  successful  replication 
of  Barrow’s  process.  None  of  these  “VERIFY”  efforts  provided  significant  detail  on  how  to 
replicate  the  verification  code.  An  actual  implementaion  of  the  verification  methodology 
described  in  VERIFY  (1)  is  the  product  of  this  thesis.  Barrow’s  methodology  is  best 
understood  by  the  presentation  of  an  example.  The  counter-circuit  example  given  by 
Barrow  (1:440-445)  will  be  discussed  using  the  Prolog  clauses  as  developed  for  this  thesis. 


3-1 


3-2 


/*******************  ;i*4^*******************************/ 

/*  *t 
/*  Counter. pro  */ 
/*  */ 
/*  Module  definitions  for  the  counter  example  */ 
/*  in  Barrow’s  VERIFY  article.  */ 
/*  */ 
/******************************************************/ 


/*- 


module.name(inc) . 


INCREMENTER 


■*/ 


port (inc , in(Anlnc) , input , integer) . 
port (inc, out (Anlnc) .output, integer) . 

/*  Behavior  Specification  *1 

output.eqnCinc,  out (Anlnc)  :*  1  +  in(Anlnc)), 

/* -  MULTIPLEXER  - 


module_name(mux) . 

port (mux , inO ( AMux) , input , integer) . 
port (mux , ini (AMux) , input , integer) . 
port (mux , switch (AMux) , input .boole) . 
port (mux , out (AMux) , output , integer) . 

/*  Behavior  Specification  */ 

output_eqn(mux,  out(AMux)  :*  if (switch (AMux) , 

ini (AMux) , 
inO(AMux))) . 
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/* .  REGISTER - */ 

module.name(reg) . 

port (reg, in (AReg) .input, integer) . 
port (reg , out (AReg) , output , integer) . 

/*  Behavior  Specification  */ 

state.of (reg, contents (AReg) .integer) . 

output_eqn(reg,out(AReg)  :*  contents (AReg) ) . 

state_eqn(reg, contents (AReg)  :»  in(AReg)). 

/* -  COUNTER - */ 

module_name (counter) . 

port (counter, in(ACounter) , input , integer) . 
port (counter, Ctrl (ACounter) , input, boole) . 
port (counter , out (ACounter) , output , integer) . 

part(counter,muxA(ACounter) ,mux) . 
part(counter,regA(ACounter) ,reg) . 
part (counter, incA (ACounter) ,inc) . 

connected(counter, Ctrl (ACounter) , switch (muxA (ACounter))) . 
connected(counter,in(ACounter) , ini (muxA (ACounter))) . 
connected(counter,out(muxA(ACounter)) ,in(regA (ACounter))) . 
connected(counter,out(regA(ACounter)) ,in(incA (ACounter))) . 
connected(counter,out(incA(ACounter)) ,inO(nuxA (ACounter))) . 
connected(counter,out(regA(ACounter)) , out (ACounter)) . 

/*  Behavior  Specification  */ 

state.of (counter, count (ACounter) .integer) . 
state_map(counter,count(ACounter) ,contents(regA(ACounter))) . 

output_eqn(counter, out (ACounter)  :=  count (ACounter)  ). 

state_eqn(counter,  count (ACounter)  :*  if (ctrl (ACounter) , 

in (ACounter) , 

count (ACounter)  +  1)). 


3-4 


The  counter-circuit  comprises  a  register  (reg),  a  multiplexer  (mux),  and  an  incre- 
menter  (inc).  Each  module  must  contain  its  own  module-name  which  uniquely  identifies 
each  module  to  be  verified  or  later  used  as  a  component  for  a  larger  module.  Each  module 
h.is  ports  which  are  associated  with  the  specific  module.  In  the  port  clause, 

port (Module , Name ,1/0 .Type) , 

Name  uniquely  identifies  each  input/output  port  for  the  module  with  module-name,  Module. 
I/O  distinguishes  between  input/output  ports  and  the  signal  type  (boole, integer,. .. )  is 
identified  by  Type. 

The  current  definition  of  a  ‘primitive*  module  is  one  which  contains  no  part  clauses. 
The  part  clause, 


part (Module , Name , SubModule) , 

is  the  method  to  hierarchically  define  the  Module.  The  Name  attribute  is  the  identifier  for 
a  specific  SubModule.  Name  is  supplied  as  SubModuleA(AModule),  SubModuleB(AModule), 
....  SubModules  are  verified  prior  to  deriving  the  behavior  of  Module.  Using  Prolog  vari¬ 
ables  (AModule)  as  part  of  the  Name  specification  provides  a  direct  method  of  instantitiating 
each  SubModule  behavior  as  part  of  the  Module  behavior.  This  provides  for  Barrow’s  sub¬ 
stitutional  model  for  deriving  behavior.  A  Module’s  Submodule’s  derived  behavior  is 
merely  substituted  for  the  SubModule ’s  output  at  the  appropriate  time  in  the  process  of 
deriving  the  Module’s  behavior. 

Deriving  a  Module’s  behavior  makes  use  of  the  part,  connected,  state_of ,  state-map, 
output.eqn,  and  state.eqn  clauses.  The  process  of  deriving  behavior  and  state  will  be 
discussed  in  the  Program  Development  chapter.  The  connected  clause, 

connected (Module, Source, Destination), 

describes  all  interconnections  of  a  Module.  Each  module  connection  is  specified  from 
Source  to  Destination  with  SubModule  identifiers  included  to  provide  the  substitutional 
method  for  deriving  behavior  previously  mentioned. 


3-5 


Each  output  of  a  module  i6  specified  in  an  output.eqn  clause, 


output.eqn  (Module ,  Output  :*=  Specif ied_Behavior) , 

which  provides  the  Specif  ied-Behavior  to  be  compared  to  the  behavior  derived  from  the 
structural  specification  (i.e.,  port,  part,  and  connected  clauses). 

At  this  point  in  the  AFIT.VERIFY  development,  and,  as  reported  by  Bariow.  only 
modules  with  internal  feedback  loops  broken  by  state  variables  (typically  registers)  (1:450— 
451)  have  been  considered.  The  dotted  line  in  Figure  3.1  represents  this  conceptual  break. 
The  state_of ,  statejaap,  and  state.eqn  clauses  allow  state  specification.  The  state.of 
clause, 


state.of (Module , State .Type) , 

simply  identifies  each  state  variable  to  the  external  environment.  This  allows  the  specifi¬ 
cation  of  Module  as  a  black  box.  The  statejaap  clause, 

statejaap  (Module ,  S  tate ,  Internals  sate) , 

shows  the  actual  internal  component,  Intemal_State,  which  contains  the  actual  State. 
Again,  State  and  Internal-State  contain  variables  to  allow  the  derivation  of  the  expected 
next  state  via  the  substitutional  process.  In  the  state_eqn  clause, 

8tate_eqn(Module, State  :*  Next-State), 

Next-State  is  now  the  specified  behavior  to  progress  to  the  next  State.  Next-State  is 
compared  to  a  derived  next  state  to  determine  equivalence. 

3.3  AFIT.VERIFY  Methodology 
AFIT.VERIFY  is  invoked  by  typing 

verify (Module) 
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after  loading  the  appropriate  Module  descriptions  and  code  (see  Appendix  2  for  sample 
runs).  The  verify  clauses  serve  as  a  main  program.  First,  the  verify  clauses  recursively 
verify  each  Subnodule.  If  all  SubModules  are  successfully  verified,  the  behavior  of  each  of 
Module’s  outputs  is  derived  and  then  compared  to  the  specified  behavior  for  each  output. 
A  derived-behavior  (Module,  Output, Derived_Behavior)  fact  for  each  equivalent  output 
is  asserted  into  the  database  for  later  use  as  a  verified  Derived-Behavior  for  the  Module. 
If  all  derived  behaviors  and  specified  behaviors  are  equivalent  (a  Module  with  no  state  is 
verified  at  this  point),  all  next  states  are  derived  and  compared  to  their  specified  next  states. 
Each  equivalent  next  state  is  asserted  as  a  next_state(Module, State, Next-State)  fact 
into  the  database  for  later  use  as  a  verified  Next-State  for  the  Module.  If  this  is  successful, 
the  module  is  verified  and  a  verif  ied(Module)  fact  is  asserted  into  the  database  for  future 
use  by  other  modules.  Various  issues  of  what  to  assert  into  the  database,  when  to  assert, 
and  how  to  assert  will  be  discussed  in  the  Program  Development  chapter. 

3.4  Summary 

Barrow  provided  a  methodology  for  performing  hierarchical  formal  verification.  This 
included  an  algorithm  and  a  specific  method  to  provide  behavioral  and  structural  speci¬ 
fications.  The  algorithm:  verify  a  module’s  components;  derive  the  behavior  of  all  out¬ 
puts/states  from  the  module’s  structure;  and  determine  if  each  derived  output/state  is 
equivalent  to  its  specified  output/state,  is  followed  by  AFIT-VERIFY.  Barrow’s  specifica¬ 
tion  syntax  is  also  strictly  adhered  to  when  possible.  This  specification  syntax  provides 
Prolog  with  specific  facts  about  a  module.  AFIT-VERIFY  then  performs  one  possible 
implementation  of  Barrow’s  algorithm  on  these  module  facts. 
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IV.  Program  Development 


4.1  Introduction 

Based  on  Barrow’s  work  (1),  AFIT-VERJFY  was  developed  in  three  major  portions. 
The  first  section  recursively  verifies  a  module’s  components.  The  next  section  derives 
a  behavioral  description  from  the  provided  structural  description,  and  the  final  section 
determines  the  equivalence  of  the  derived  and  specified  behavioral  descriptions.  Before 
explaining  what  each  portion  of  code  provides,  some  comments  on  the  development  envi¬ 
ronment  and  methodology  will  be  disussed. 

4.2  Development  Environment 

The  majority  of  code  was  developed  on  a  PC  using  PROLOG-1.  This  caused  some 
minor  modifications  to  Barrow’s  naming  conventions  since  the  clause,  state,  has  special 
meaning  to  PROLOG-1.  The  clause  state.of  is  used  in  place  of  Barrow’s  state  clause. 
The  PC  environment  allowed  for  rapid  prototyping  by  using  Sidekick  to  make  coding 
changes  and  then  popping  back  into  PROLOG- 1  to  run  the  improved  code. 

PROLOG-1  has  some  shortcomings,  the  most  significant  being  insufficient  stack 
space.  This  was  realized  during  the  verification  of  Barrow’s  counter-circuit  example  ( 1 .440- 
445).  During  the  process  of  determining  the  equivalence  of  the  sum  output’s  specified  and 
derived  behaviors,  the  stack  space  was  exceeded.  This  presented  two  alternatives:  make 
the  Boolean  expansion  code  (6)  more  efficient,  or  move  to  a  larger  system.  Work  contin¬ 
ued  on  the  AFIT  Microvax  system  Cub  using  Quintus  Prolog  since  it  became  apparent 
PROLOG-1  would  not  be  sufficient  for  larger  modules. 

The  counter-circuit  example  was  verified  on  Cub,  but  not  without  some  minor  porta¬ 
bility  problems.  Quintus  Prolog  has  no  not  clause  defined.  (In  Prolog,  not  is  understood 
to  mean  that  no  clause  of  the  specified  type  exists.  The  goal,  not  parent (X,Y)  succeeds 
when  no  parent  clauses  appear  in  the  database.)  More  imporcantly,  the  operator  prece¬ 
dences  in  Quintus  Prolog  run  from  0  to  1200  but  only  from  0  to  255  in  PROLOG-1.  Also, 
the  clause  module,  has  system  significance  to  Quintus;  therefore,  module  was  changed  to 
module_naine.  Finally,  Quintus  Prolog  provides  better  error-checking  mechanisms.  One 
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of  these  mechanisms  checks  for  the  redefinition  of  a  clause  when  a  new  file  is  loaded.  A 
programmer  cannot  redefine  clauses  in  separate  .pro  files  unless  a  multifile  directive  is 
included  for  each  clause  which  needs  to  be  redefined.  Unless  the  AFIT.VERIFY  code  is  to 
be  kept  as  one  huge  .pro  file,  redefinition  of  clauses  in  separate  files  would  be  required,  since 
each  new  module  would  require  redefinition  of  the  module_name,  part,  port,  . .  .clauses. 
The  multifile  directives  are  included  in  the  qops.pro  file.  Two  separate  operator  files, 
qops.pro  (Quintus)  and  ops.pro  (PROLOG-1),  were  created  to  provide  a  mechanism  for 
system  portability.  Additional  operator  files  can  be  created  for  use  on  other  Prolog  sys¬ 
tems.  In  fact,  follow-on  work  is  expected  to  be  completed  on  a  PC  version  of  Quintus 
Prolog,  and  discrepancies  between  the  PC  and  mainframe  versions  should  be  handled  in 
the  operator  files. 

4.3  Verify 

The  first  goal  was  to  verify  a  simple  combinational  circuit,  like  an  Exclusive-OR 
gate  comprising  NAND  gates.  This  proved  to  be  simple.  The  next  step  was  to  verify  a 
sequential  circuit,  one  which  contained  a  single  state  variable.  The  example  demonstrated 
by  Barrow  and  implemented  in  AFIT.VERIFY  was  a  simple  counter-circuit. 

This  task  was  not  trivial  and  introduced  many  new  concepts  to  the  design.  After 
studying  a  similar  verification  attempt  by  Brezocnik  et  al.  (3),  it  finally  became  apparent 
that  a  modular  and  easily  expandable  design  should  be  used.  This  required  a  relook  at 
the  code  used  to  verify  the  combinational  circuit. 

The  first  attempt  at  a  verification  procedure  looked  like  this: 


verify (Module) 

verify.,  components  (Module) , 

derive_behavior(Module,out(X) ,Derived_Behavior) , 
equal.behaviors (Module , Derived.Behavior) , 
as8erta(verif ied (Module) ) . 


In  the  spirit  of  declarative  programming,  Prolog  was  told  to  perform  the  three  parts 
of  Barrow’s  VERIFY  algorithm:  verify  the  components,  extract  a  behavior  from  the  struc- 
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ture,  and  then  compare  the  extracted  behavior  to  the  specified  behavior.  This  approach 
works  well  for  a  combinational  circuit  with  a  single  output,  but  what  about  a  sequential 
circuit  or  circuits  with  multiple  outputs?  Since  Prolog  is,  in  essence,  a  relational  database, 
it  was  decided  to  use  the  database  capabilities  to  provide  and  update  the  appropriate  state 
information.  This  is  a  variation  of  the  technique  used  by  Grabowiecki  et  al.  (10:40).  All 
parts  of  the  program  would  have  access  to  the  asserted  facts.  It  was  also  determined  that 
the  verify  clauses  would  operate  as  drivers.  In  so  doing,  the  verify  clauses  would  be 
required  to  handle  the  different  types  of  modules  to  be  verified.  This  required  a  different 
verify  clause  for  each  type  of  module  (i.e.  previously  verified,  primitive,  no  state,  . . . ). 
This  also  created  the  need  for  helper  procedures  to  generate  and  verify  multiple  outputs, 
states,  and  components. 

The  different  types  of  modules  to  be  verified  are  handled  by  the  following  verify 
clauses: 


verify (Module)  /*  previously  verified  module  */ 

verif ied(Module) , 

•  9 

writeln([’»>*, Module,’  previously  verified  »>’]). 
verify (Module)  /*  primitive  module  with  no  state  */ 

not  part (Module, _,_) , 
not  state_eqn(Module,_) , 

i 

•  » 

asserta(verif ied(Module)) , 

writeln([’»>’ .Module,’  primitive  (needs  no  verification) >»’]) . 
verify (Module)  /*  primitive  module  with  state  */ 

not  part (Module, _,_) , 

i 

•  f 

asserta(verified(Module)) , 

writeln([’»>’  .Module,’  primitive  (needs  no  verification) »>’]) . 
verify (Module)  /*  non-primitive  with  no  state  */ 

not  state_eqn(Module,_) , 

writeln([’»>  Attempting  to  verify  ’  .Module, ’>»’]) , 
verif y.components (Module) , 

•  9 

derive_and_equate_behaviors (Module) , 
asserta(verified(Module)) , 

writeln([’«<  Success!  Behavior  of ’ .Module, ’meets  its  specification.’]). 
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verify (Module)  /*  non-primitive  with  state  */ 

writeln([’»>  Attempting  to  verify  *  .Module,* >»’]), 
verify.components (Module) , 

i 

•  t 

derive.and.equate.behaviors (Module) , 
derive_and_equate_atates (Module) , 
asserta(verif ied(Module) ) , 

writeln([*«<  Success!  Behavior  of  * .Module, ’meets  its  specification.']). 

These  five  clauses  should  handle  any  type  of  Module  to  be  verified.  Some  decisions 
were  made  about  primitives  which  would  impact  other  portions  of  the  code.  For  a  primitive 
module,  behavior  is  equivalent  to  structure,  or  more  importantly,  the  derived  behavior  is 
the  specified  behavior.  At  this  time,  no  derived-behavior  (Module,  Output,  Behavior)  or 
next-state  (Module,  State,  Nextstate)  facts  are  asserted  into  the  database  for  primitive 
modules  since  this  information  can  be  obtained  directly  from  the  output.eqn (Module, 
Output  :®  Behavior)  and  state_eqn(Module,  State  Nextstate)  clauses.  If  it  is 
later  decided  that  the  derived-behavior  and  next-state  clauses  should  be  asserted,  then 
a  clause  can  be  removed  from  the  derive_behavior  clauses  (Rule  2A).  A  similar  decision 
is  required  for  the  asserta(verified(Module))  for  a  primitive  Module.  With  only  one 
possible  verified  clause  per  Module,  the  space  required  seems  minimal  for  the  time  sav¬ 
ings.  The  time  savings  can  be  achieved  due  to  the  use  of  cuts  (!)  in  the  verify  clauses. 
The  cuts  remove  the  need  for  resatisfaction  of  goals  like  part  (Module ,  _,  _)  as  Prolog  works 
its  way  through  the  clauses. 

The  helper  clauses  derive_and_equat e-behaviors ,  derive_and_equate_states,  and 
verify-components  allow  the  verify  clauses  to  hierarchically  verify  each  component  of 
a  Module  and  ensure  that  all  outputs  and  states  are  equivalent.  Since  the  fail  clause 
always  returns  false,  the  second  clauses  in  the  helper  procedures  check  that  the  first 
clause  did  the  appropriate  work.  The  second  clauses  in  derive_and_equate_behaviors 
and  derive_and_equate_states  count  the  number  of  derived  and  specified  behaviors.  If 
the  numbers  are  equal,  then  the  first  clause  derived  and  equated  all  the  outputs/states. 
This  assumes  that  the  procedures  determining  the  equivalence  of  the  derived  and  specified 
behaviors  are  correct.  If  these  clauses  fail,  then  cleanup  can  be  performed  by  retracting 
the  asserted  clauses.  The  verify.components  clauses  create  a  list  of  the  module’s  com- 
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ponents  (parts)  using  set-of  and  checks  that  a  verified  fact  has  been  asserted  using 
parts_verified.  It  should  be  noted  that  Quintus  Prolog  has  a  system-defined  clause 
setof  (Objects, Predicate, List)  which  returns  the  List  of  the  set  of  Objects,  which 
satisfy  the  Predicate.  The  behavior  of  setof  was  not  as  expected.  Since  PROLOG-1 
has  no  setof  clause  defined,  the  clauses  set_of ,  f  ind_all,  and  length_of  are  provided  in 
both  operator  files  to  ensure  portability.  The  helper  procedures  are  as  follows: 


derive.and.equate.behaviors (Module )  :  - 
derive.behaviors (Module, Output ,Derived_Beh) , 
equal.behaviors (Module , Output ,Derived_Beh) , 
asserta(derived_behavior (Module, Output ,Derived_Beh) ) , 
fail. 

derive.and.equate.behaviors (Module) 

set.of (Outputs, output_eqn(Module, Outputs  :=  _) .Outlist) , 
length(Outlist , Outnum) , 

set.of (Outputs, derived.behavior (Module, Outputs,.) .Derlist) , 
length(Derlist  .Demum) , 

Outnum  »:*  Dernum. 

derive.and.equate.behaviors (Module)  :  - 
retract (derived.behavior (Module ,_,_) )  , 
fail. 

derive.and.equate.states (Module)  : - 

derive.states (Module, State, Next.State) , 
equal. st ates (Module .State , Next .State) , 
assert a(next_8t ate (Module, State, Next. State)) , 
fail. 

derive.and.equate.states (Module)  :  - 

set.of (States, state.eqn (Module, States  :«  .) .Statelist) , 
length(Statelist.Statenum) , 

set.of (States .next.state (Module, States,.), Derlist) , 
length (Derlist .Dernum) , 

Statenum  «:«  Dernum. 

derive_and_equate.state8(Module) 
retract (next.state (Module ,_, _) ) , 
fail. 

verify.components (Module) 
part (Module , _ .Component) , 
verify(Component) , 
fail. 
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verif y.componenta (Module)  : - 

set.of (Component .part (Module Component) .Compliat) , 

p  rts.verif ied(Complist) , 

writ eln(C' component  list  is  ’ ,  Complist]). 

parts_verif ied(  □  ) . 
parts..verif  ied(  [Component  I  Tail] ) 
verif ied (Component) , 
parts.verif ied(Tail) . 


This  portion  of  the  code  should  require  no  foreseeable  modifications  when  AFIT  .VERIFY 
is  expanded. 


4.4  Deriving  Behavior 

“One  key  principle  underling  VERIFY  is  that,  given  the  behaviors  of  components  of 
a  system  and  their  interconnections,  it  is  possible  to  derive  a  description  of  the  behavior  of 
the  whole  system”  (1:445).  The  code  provided  in  this  section  is  one  possible  implementation 
of  VERIFY’s  method  for  deriving  behavior. 

Since  some  devices  have  an  associated  state  and  some  devices  are  simply  combina¬ 
tional  logic,  different  types  of  behavior  must  be  derived.  However,  all  devices  are  described 
by  at  most  two  types  of  equations:  output  equations  and  next  state  equations.  Barrow’s 
notation  is  used  in  the  following  representations  for  a  specified  behavior: 

output.eqn(Module,  Out  :*  Function) 
state_eqn(Module,  Next-State  :=  Function). 

The  8tate_eqn  notation  became  very  confusing,  since  the  state.eqn  really  referred  to  the 
equation  for  the  next  state  in  a  sequential  machine.  To  somewhat  remove  this  ambiguity, 
when  a  behavior  is  derived,  the  following  clauses  are  asserted  into  the  database: 


derived-behavior  (Module ,  Output ,  Behavior) 
next-state (Module, State, Function). 


This  helps  the  programmer  to  remember  that  the  prototype  is  really  deriving  the 
expected  output  and  next  state.  Asserting  these  clauses  in  the  database  also  frees  the 
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programmer  from  passing  parameters  in  the  heads  of  clauses.  Asserting  these  clauses  is  a 
variation  of  the  technique  used  by  Grabowiecki  et  al.  (10:40). 

Now,  all  that  would  be  required  to  derive  the  behavior  of  a  module  would  be  to  type: 

derive_and_equate-behaviors  (Module)  and/or 
derive_and_equate_states  (Module) . 

These  clauses,  when  invoked  by  a  verify  clause  for  the  appropriate  module  types,  extract 
the  Outputs  and  Next-States  from  the  module  specifications  and  derive  the  appropriate 
behavior.  The  clause,  derive-behaviors  is  used  to  extract  the  information  for  outputs  and 
then  invoke  the  derive  behavior  clause  to  actually  derive  the  behavior  for  the  specified 
output.  If  a  Module  has  state,  some  internal  variables  may  need  to  be  removed  from  the 
derived  behavior.  This  is  the  reason  for  two  derive-behavior  clauses  and  the  need  for 
the  substitute-state  clause.  The  code  is  as  follows: 

derive-behaviors (Module, Form, Behavior)  /*  no  state  */ 

not  state_eqn(Module,-) , 

!. 

output.eqn (Module, Form  :«Spec_Behavior) , 
derive.behavior(Module .Form, Behavior) . 

derive.bebaviors (Module, Form, Behavior)  /*  has  state  (!),  */ 

output_eqn(Module,Form  :*  Spec -Behavior) , 
derive-behavior (Module , Form , TBehavior) , 

substitute-State(Module, TBehavior, Behavior) .  /*  might  require  */ 

/*  the  removal  of  some  internal  variables.  */ 

The  majority  of  work  is  performed  by  the  derive-behavior  clauses.  These  clauses 
work  their  way  through  the  connected  clauses  for  each  output  until  a  module  terminal  is 
reached.  The  process  is  a  simple  substitutional  one  which  would  be  used  by  humans.  For 
example,  given  the  following  NAND  and  XOR  module  specifications, 


4-7 


/* -  Structural  Specification  for  2-input  nand  - */ 

module_name(nand2) . 

port(nand2,inO(ANand2) .input, boole) . 
port (nand2 , ini (ANand2) , input .boole) . 
port (nand2 , out (ANand2) , output .boole) . 

/*  Behavioral  Specification  */ 

output_eqn(nand2 , 

out(ANand2)  :*  or(  neg(inO(ANand2)) ,  neg(inl(ANand2)))  ). 


/*  Structural  specification  for  a  two-input  Exclusive-OR  */ 

module.name(xor) . 

port(xor,inO(AnXor) .input .boole) . 
port (xor , ini (AnXor) , input .boole) . 
port (xor, out (AnXor) .output, boole) . 

part (xor, gl (AnXor) ,nand2) . 
part (xor, g2 (AnXor) ,nand2) . 
part (xor, g3 (AnXor) ,nand2) . 
part (xor, g4(AnXor) ,nand2) . 

connected (xor , inO (AnXor) , inO (gl (AnXor) ) ) . 
connected(xor, ini (AnXor) , ini (gl (AnXor)) ) . 
connected(xor,inO(AnXor) ,in0(g2 (AnXor))) . 
connected(xor, out (gl (AnXor)) , ini (g2 (AnXor))) . 
connected(xor , out (gl (AnXor) ) , inO (g3 (AnXor) )) . 
connected (xor , ini (AnXor) , ini (g3 (AnXor) ) ) . 
connected (xor, out (g2 (AnXor)) ,in0(g4 (AnXor) )) . 
connected (xor, out (g3( AnXor)) ,inl(g4(AnXor))) . 
connected (xor, out (g4 (AnXor) ) , out (AnXor) ) . 

/*  Behavioral  Specification  for  a  two-input  XOR  */ 

output_eqn(xor , 

out(AnXor)  or(  and(  neg(inO( AnXor)) , 

ini (AnXor)  ), 
and(  inO (AnXor), 

neg(inl(AnXor))  )))., 
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the  following  output  behavior  is  derived: 


or(and(in0(_755) , 

or(neg(in0(_755)) ,neg(inl(.755)))) , 
and(or(nag(in0(_755)) ,neg(inl(_755))) , 
ini (.755))) 

The  form  is  canonicalized,  but  one  can  see  that  the  outer  OR  is  g4,  the  ANDs 
inside  the  OR  are  g2  and  g3  and  the  or(neg(in0(_755))  ,neg(inl(_755)))  is  the  output 
of  gl.  All  gate  outputs  have  simply  been  replaced  with  their  derived  behavior  (Since  a 
NAND  gate  is  considered  primitive,  the  derived  behavior  of  a  NAND  gate  is  the  specified 
behavior).  A  human  would  obtain  this  by  working  his  way  back  through  the  NAND  gates, 
substituting  the  appropriate  output  equation  for  the  NAND  gates  until  the  terminal  inputs 
are  reached.  This  is  a  simple  recursive  process  which  is  duplicated  by  the  derive -behavior 
clauses.  Along  the  way,  a  simple  substitution  of  a  submodule’s  derived  behavior  is  made 
when  a  submodule’s  output  is  encountered.  Boolean  or  mathematical  equations  are  further 
expanded  and  canonicalized.  Any  type  of  behavior  not  captured  by  some  Boolean  or 
mathematical  rule  is  simply  returned  unchanged. 

The  derive_behavior  clauses  are  arranged  in  three  groups.  The  first  group  traverses 
through  the  connected  statements  (Rules  1 A  and  IB).  The  next  group  replaces  outputs  with 
their  appropriate  behaviors  (Rules  2A  and  2B).  The  rules  in  the  remaining  groups  simplify 
and  canonicalize  the  behavior  obtained  from  the  first  two  groups.  All  derive_behavior 
clauses  have  the  following  form: 

derive.behavior (Device, Formula, Behavior) 

Device  is  the  gate  or  component  whose  behavior  is  being  derived,  such  as  NAND,  XOR, 
or  counter.  Formula  is  the  type  of  behavior  to  be  derived  such  as  out(X)  or  some  state 
variable  equivalent  such  as  in(regA(X)).  Behavior  is,  of  .course,  the  resulting  derived 
behavior.  The  types  of  clauses  developed  are  the  following: 
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derive .behavior (Module,  Fora,  Source) 
connected (Module,  Source,  Form), 
primary.source (Source) , 

! ,writeln( [’Applying  Rule  1A  to  ’.Form]), 
derive.behavior (Module,  Form,  Behavior)  :- 
connected(Module,  Source,  Form), 
derived_8ource (Source) , 

! ,writeln([’ Applying  Rule  IB  to  ’ ,  Form]), 
derive.behavior (Module,  Source,  Behavior). 


derive.behavior (Module,  Form,  Behavior)  :- 
Form  \=*  i, 

Form*..  [F,G], 

part (Module,  G,  Component), 

not  part (Component,., _) ,  /*  Component  is  a  primitive  module  */ 

output.eqn (Component,  Form  :*  OutForm), 

! ,writeln( [’Applying  Rule  2A  to  *,  Form]), 
writeln( [Component,  ”  *s  output  equation:’]), 
writeln([’  ’,  Form,  ’  :*  ’,  OutForm]), 

derive.behavior (Module,  OutForm,  Behavior).  /*  replace  gate  */ 

I*  inputs  with  module  variables  */ 
derive.behavior (Module,  Form,  Behavior) 

Form  \=*  1, 

Form*..  [F,G], 

part (Module,  G,  Component),  /*  tion  cut,  no*  primitive  component  */ 
/*  previously  verified  due  to  verify. components  in  verify  clause  */ 
derived_behavior(Component .Form, OutForm) , 

! ,writeln([* Applying  Rule  2B  to  ’,  Form]), 
writeln( [Component, * ’ ’s  derived  behavior: ’] ) , 
writeln([’  ’,  Form,  ’  :*  ’,  OutForm]), 

derive.behavior (Module, OutForm, Behavior) .  /*  replace  gate  */ 

/*  inputs  with  module  variables  */ 


derive.behavior (Module,  neg(Form),  Behavior)  :- 
! ,writeln([’ Applying  Rule  3  to  ’ ,neg(Form)] ) , 
derive.behavior (Module,  Form,  Behl), 
evaluate!. (neg(Behi) ,  Behavior), 
derive.behavior (Module,  and(Forml,Form2) ,  Beh)  :- 
! ,writeln( [’Applying  Rule  4  to  ’ ,and(Forml,Form2)]) , 
derive.behavior (Module,  Forml,  Behl), 
derive.behavior (Module,  Form2,  Beh2) , 
evaluatel(and(Behl,Beh2) ,  Beh). 


4-10 


derive.behavior (Module,  or(Forml,Form2) ,  Beh) 

! ,writeln([* Applying  Rule  5  to  * ,or(Forol,Fonn2)] ) , 
derive.behavior (Module,  Forml,  Behl), 
derive.behavior (Module,  Form2,  Beh2) , 
evaluate!. (or (Behl, Beh2) ,  Beh) . 
derive.behavior (Module,  if (Cond,Texp,Fexp) ,  Beh) 

! .writ eln([’ Applying  Rule  6  to  ’ ,if (Cond,Texp,Ferp)]) , 
derive.behavior (Module,  Cond,  NCond) , 
derive.behavior (Module,  Texp,  NTexp) , 
derive.behavior (Module,  Fexp,  NFexp) , 
evaluatel (if (NCond, NTexp, NFexp) ,  Beh) . 
derive.behavior (Module,  First  +  Second,  Beh) 

! ,writeln([’Applying  Rule  7  to  ’ .First  +  Second]), 
derive.behavior (Module,  First,  Behl), 
derive.behavior (Module,  Second,  Beh2) , 
evaluatel (Behl  +  Beh2,  Beh). 

derive.behavior (Module,  Form,  Form)  /*  default  Rule  */ 

writeln( [’Applying  default  Rule  to  ’.Form]). 


The  clauses  primary-source  and  derived-source  are  introduced  in  the  first  two 
derive_behavior  clauses.  The  primary-source  and  derived-source  clauses  distinguish 
between  a  Module  input  (primary .source)  and  a  Component  input/output  (derived-source). 


primary.source (Source) 

Source  =..  [.,Arg], 
var(Arg) . 

derived.source (Source) 

Source  = . .  [_,Arg] , 

Arg*..  [_,Arg2], 
vapr(Arg2) . 

Any  new  type  of  behavior  needed  to  expand  AFIT-VERIFY  would  require  new 
derive_behavior  clauses.  Again,  if  the  decision  is  made  to  assert  a  derived-behavior 
fact  for  primitive  modules,  then  Rule  2A  could  be  removed.  The  evaluatel  procedure  is 
introduced  in  this  code.  It  is  merely  a  preliminary  simplification  of  the  derived  behavior. 
The  clause  evaluatel  is  simply  a  test  clause  which  invokes  evaluate.brown  and  prints 
the  behavior  before  and  after  simplification.  The  evaluate_brovn  clauses  actually  per¬ 
form  the  simplification  and  rudimentary  canonicalization.  As  with  the  derived-behavior 
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clauses,  e valuate.br own  clauses  will  need  to  be  added  when  new  behaviors  are  added.  The 
first  three  evaluate_brown  clauses  provide  basis  cases  for  a  behavioral  structure,  namely 
a  variable,  atom,  or  an  elementary  structure.  The  next  three  clauses  provide  a  method  of 
simplification  and  canonicalization  of  the  Boolean  functions  AND,  OR,  and  NOT.  Another 
canonical  form  may  prove  quicker;  in  that  case,  these  clauses  would  need  to  be  modified 
accordingly.  The  identifier  neg  has  been  chosen  as  the  negation  functor,  as  opposed  to  the 
more  widely  used  not,  since  Prolog  defines  the  goal  not  P  to  succeed  in  case  the  goal  P 
fails  (i.e.,  cannot  be  proved)  in  the  existing  database.  The  clause  not  is  not  provided  in 
Quintus  Prolog.  This  is  why  not  is  defined  in  the  qops.pro  file.  The  remaining  clauses 
provide  a  method  of  simplification  and  canonicalization  of  the  operators  required  to  verify 
the  fulladder  and  counter,  namely,  if  and  +. 


evaluate!. (X, EX) 

writeln( [’Value  of  ’,X, ’:*]), 
evaluate.brown (X , EX) , 
writeln([’  ’,EX]). 

evaluate_brown(X,X) 
var(X) , ! . 

evaluate_brown(X,X) 
atomic (X) , ! . 

evaluate.brown(Struct, Struct) 
Struct  [F.Arg], 

(  var(Arg)  ;  atom(Arg)  ) , ! . 

evaluate_brown(and(X,Y) , Value)  : 
evaluate_brown(X,EX) , 
evaluate_brown(Y,EY) , 

(  (EX  «  0  ;  EY  «  0) ,  « , 

Value  *  0 

» 

EX  *  1,  ! , 

Value  *  EY 

f 

EY  *  1,  ! , 

Value  =  EX 

9 

! .Value  =  and(EX.EY) 

). 
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evaluate_brown(or(X,Y) .Value) 
evaluate_brown(X,EX) , 
evaluate_brown(Y,EY) , 

(  (EX  -  1  ;  EY  «  i) ,  ! , 

Value  *  1 

» 

EX  ■  0,  !, 

Value  «  EY 

l 

EY  «  0,  !, 

Value  «  EX 

I 

!, Value  «  or(EX,EY) 

). 

evaluate_brown(neg(X) .Value) 
evaluate_brown(X,EX) , 

(  var(EX) ,  ! , 

Value  *  neg(X) 

9 

EX  -  0,  ! , 

Value  *  1 

EX  -  1,  ! , 

Value  »  0 
I 

atom(EX) ,  ! , 

Value  ■  neg(EX) 

i 

EX  *  neg(N) ,  ! , 

Value  *  N 
I 

EX  *  and(Al,A2),  !, 
evaluate.brown (neg ( A 1 ) ,NA1) , 
evaluate_brovn(neg(A2) ,NA2) , 
Value  *  or(NAl,NA2) 

I 

EX  *  or(0i,02),  ! . 
evaluate_brovn(neg(01) ,N01) , 
evaluate_brown(neg(02) ,N02) , 
Value  *  and(N01,N02) 

9 

! .Value  =  neg(EX) 

). 
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evaluat e_brown ( if (Cond , Texp , Fexp ) , Value ) 
evaluate_brown(Cond, NCond) , 
evaluate_brown(Texp , NTexp) , 
evaluate_brown(Fexp, NFexp) , 

(  (  NCond  ■  1 ,  ! , 

Value  «  NTexp  )  ; 

(  NCond  «  0,  ! , 

Value  *  NFexp  )  ; 

(  NTexp  *  NFexp ,  ! , 

Value  »  NTexp  )  ; 

Value  *  if (NCond.NTexp, NFexp), 

!  ). 


/*  Condition  is  true  */ 
/*  return  True  exp  */ 
/*  If  False  then  */ 
/*  return  False  exp  */ 
/*  Condition  irrelevant  */ 
/*  if  choices  equal  */ 
/*  otherwise  return  */ 
/*  simplified  expression.  */ 


evaluat e_brown(X+Y , Z) 
integer(X) , 
integer(Y),  !, 

Z  is  X  +  Y.  /*  force  simplification  of  1  +  2  =  3  */ 

evaluate_brown(X+Y,Z) 

integer(Y) , ! ,  /*  X  not  integer  due  to  cut  */ 

evaluate_brown(X,NewX) , 

Z  *  Y  +  NewX.  /*  canonicalize  with  integer  first  */ 

evaluate_brown(X+Y,Z) 

! , evaluate_brown(X,NewX) , 
evaluat e_brown(Y,NewY) , 

Z  *  NewX  +  NewY. 


evaluat e.brown(X.X) . 


/*  default  simplification  for  complex  */ 
/*  structures  like  in(incA(X)).  */ 


Deriving  the  next  state  is  only  a  variant  of  deriving  the  behavior  of  an  output. 
The  state  variable  and  its  internal  variable  equivalents  are  extracted.  A  behavior  is  then 
derived  for  the  internal  variable,  which  is,  in  fact,  the  next-state  behavior  for  the  state 
variable.  Occurrences  of  internal  variables  in  the  derived  behaviors  are  replaced  with 
the  state  variables  when  such  simplifications  will  make  the  process  of  equating  behaviors 
simpler  (3:103).  The  replace.all  clauses  find  all  signals  in  a  derived  behavior  which  are 
connected  to  a  state  variable  in  a  module  and  replace  them  with  the  state  variable.  First, 
the  New  signal  is  substituted  for  the  Old  signal  in  the  Old  Behavior  (OldBeh)  to  create  an 
intermediate  Substituted  Behavior  (SB).  Next,  any  signal  (Other)  connected  to  tlife  Old 
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signal  is  found  and  the  substitution  process  is  repeated  (recursive  call  of  replace.all). 
The  code  required  to  derive  the  next  state  is  the  following: 


derive.states (Module, State, Next.State) 
state_of (Module, State, Type) , 
state_map (Module, State, Internal) ,/*  It’s 
state.eqn (Part, Internal  :*  NextState), 
derive.behavior (Module .NextState ,Beh) , 
subst itute.state (Module ,Beh,Next_State) . 


/*  It  has  state  */ 
mapped  to  an  internal  part*/ 
/*  Internal  state  is  a  */ 
/*  function  of  inputs  and  */ 
/*  previous  state  */ 


subst itute.st ate (Module, DerBeh.SubBeh)  : - 
state_map (Module .External , Internal) , 

i 

•  » 

writeln( [’Derived  Behavior:  * ,DerBeh] ) , 
replaceall (Module , Internal , External , DerBeh.SubBeh) , 
vriteln( [’Substituted  Behavior:  ’ .SubBeh] ) . 

replaceall (Module , Old , Nev , OldBeh , SubBeh)  : - 
replace (Old, New, QldBeh, SB) , 

(  connected (Module, Old, Other)  ; 

output _eqn (Part, Other  :»  Old)  ), 

! » 

replaceall (Module , Other , New , SB , NewSB) , 

evaluatel (NewSB, SubBeh) .  /*  Simplify  further  if  possible  */ 

replaceall (Module, Old, New ,Beh,Beh)  .  /*  no  mote  connections  */ 

replace (Old, New, Other, Other) 
atomic (Other) , 
write(’Rule2*) ,nl, ! . 
replace (Old, New, Other, Other) 
var( Other) , 
write (’ Rule3 ’) ,nl, ! , 
replace (Old, New, Other, Other) 

Old  [F.Argl],  /*  keeps  in(X)  =  in(incA(X))  */ 

Other  [G,Arg2],  /*  from  occuring,  occurs  test  */ 

F  \==  G, 

(  var(Arg2)  ;  atomic(Arg2)  ),  /*  already  simplified  */ 

write(’Rule4’),nl, ! . 

replace(01d,New,and(X,Y) ,and(NewBl,NewB2)) 

! ,write(’Rule  and’),nl, 
replace(01d,New,X,NewBl) , 
replace(01d,New,Y,NewB2) . 
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replace(01d,N«w,or(X,Y) ,or(N«wBl ,NewB2)) 

! ,write(’Rule  or’),nl, 
replace(01d, New, X, NewBl) , 
replace(01d,New,Y,NewB2) . 
replace(01d,New,neg(X) ,neg(NewB)) 

! .write (’Rule  neg’),nl, 
replace (Old, New, X.NewB) . 
replace (Old, New, X  +  Y.NewBl  +  NewB2) 

! .write (’Rule  +  *),nl, 
replace(01d,New,X,NewBl) , 
replace(01d,New,Y,NewB2) . 

replace (Old .New , if (Cond.Texp , Fexp) , if (NewBl , NewB2 , NewB3) )  : - 
! .write (’Rule  if’),nl, 
replace (Old, New, Cond, NewBl) , 
replace(01d,New,Texp,NewB2) , 
replace(01d,New,Fexp,NewB3) . 

replace(01d, New, Other, NewB)  /*  in(X)  /==  in(incA(X))  */ 

Old  *..  CF.Argl], 

Other*..  [F,Arg2], 

(  (  var(Argl),  not  var(Arg2)  ); 

(  not  var(Argl) ,  var(Arg2)  )  ), 
replace (Old, New, Arg2,NewArgs) , 

NewB  *..  [F.NewArgs],  /*  Old  behavior  or  Old  Behavior  is  */ 

write(’Rule  struct’) ,nl, ! .  /*  some  other  nested  structure  */ 

replace(01d,New,01d,New) 

write(’Rule  1’),  nl,5.  /*  If  you  find  X  replace  with  Y  */ 

replace (Old, New, Other, Other) 

write (’Default  Rule’),nl.  /*  default  rule.  */ 

As  with  derive_behavior  and  evaluate_brown,  new  replace  clauses  will  need  to 
be  added  when  new  behavioral  structures  are  created.  It  should  now  be  readily  apparent 
that  Prolog  can  be  thought  of  as  a  guided  search.  A  programmer  merely  provides  the 
type  of  patterns  which  he  wants  to  encounter.  This  is  why  new  behavioral  descriptions  are 
accomodated  by  adding  new  clauses  to  “handle”  the  new  structure. 


4.5  Determining  Equivalence 

The  majority  of  work  on  AFIT.VERIFY  went  into  developing  the  ability  to  derive 
behavior.  Determining  equivalence  of  the  two  behaviors  is  a  well-understood,  but  non¬ 
trivial  task.  The  examples  verified  have  been  limited,  and  the  need  for  extensive  work 
on  equivalence  will  arise  with  newer  and  larger  examples.  Most  of  the  work  of  determin- 
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mg  equivalence  is  accomplished  by  the  Boolean  expansion  code  created  by  CPT  Dukes 
(6:39-43).  It  is  noted  that  the  Type  attribute  in  a  port  clause  can  be  used  to  guide  the 
methods  of  determining  equivalence.  The  work  to  this  point  concentrated  on  verifying  and 
deriving  the  behavior  of  Boolean  circuits  with  the  exception  of  the  counter-circuit  exam¬ 
ple.  In  the  counter-circuit  example,  determining  equivalence  was  simplified  by  making  a 
simple  canonicalization.  Any  occurrence  of  (term  -f  integer)  was  replaced  by  (integer  + 
term).  This  allowed  the  derived  behavior  and  specified  behavior  of  count  (counter)  to  be 
trivially  equivalent.  The  following  description  and  code  provides  the  current  methods  for 
determining  equivalence. 

The  derive_and_equate_behaviors  and  derive_and_equate_states  clauses  use  the 
equal-behaviors  and  equal-states  clauses  to  provide  every  output/state  equivalence. 
The  primary  methods  used  to  determine  equivalence  are  simplification  and  Boolean  expan¬ 
sion.  The  following  code  implements  the  equivalence  portion  of  AFIT.VERIFY. 


equal_behaviors (Module , Output , Der ived.Beh)  : - 

output.eqn (Module , Output  :»  Specif ied-Beh) ,/*  get  specified  behavior  */ 
eqb (Module, Derived_Beh, Specif ied-Beh) . 
equal-states (Module, Nextstate, Derived-State) :~ 

state.eqn (Module, Nextstate  :*  Function),  /*  get  specified  state  */ 

eqb (Module , Derived-State , Funct ion) . 

eqb(M,X,X)  /*  trivial  identity  */ 

j . 

eqb(M,DB,SB)  /*  Boolean  expansion  */ 

/*  expandable (M) ,  fewer  than  too  be  determined  combinations  */ 

/*  and  Boolean  variables  */ 

evaluate_dukes(DB,NewDB) , 
evaluat e-dukes (SB, NewSB) , 

writeln([’Does  ’.NewDB,’  ■’]) ,writeln([’  NewSB]), 

eq(NewDB, NewSB) , 

writeln([DB, *  *']) ,writeln([’  *,SB]), 
writeln([*By  Boolean  Expansion’]),!. 

expandable(M)  /*  some  how.many  function  will  */ 

port(M,-,-,boole) , ! .  /*  be  required  */ 
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/*  simplification  */ 


eqb(M,DB,SB) 

evaluate!. (DB,NDB) , 
evaluatel(SB.NSB) , 

(  DB  \««  NDB  ; 

SB  \«  NSB  ) , 

writeln( [’Derived  behavior  is:  *,DB]), 
eqb(M,NDB,NSB) ,  !. 

The  clause  eq(NewDB,Ne»SB)  is  the  driver  for  the  code  which  performs  CPT  Dukes’s 
Boolean  expansion  code.  An  introduction  to  the  concept  of  Boolean  expansion  seems 
appropriate  at  this  point. 

Boole’s  Expansion.  There  are  two  basic  methods  of  determining  the  equivalence 
of  two  functions  /  and  g.  Consider  a  design  composed  of  the  following: 

t  =  1 ..  .n  inputs  and 
j  —  l...m  outputs. 

Equations  /  and  g  are  Boolean  functions  of  n  input  variables  with  m  possible  output 
values.  The  first  method  of  determining  equivalence  is  to  enumerate  all  possible  2"  input 
values  and  compare  all  m  possible  output  values.  This  approach  will  always  require  m2" 
operations  and  gets  out  of  hand  very  quickly  as  m  and  n  grow. 

The  second  approach,  which  can  have  many  variants,  is  to  perform  Boole’s  Expansion 
on  functions,  and  show  that  each  expanded  sub-function  is  equivalent.  This  can  cause 
success  much  sooner  and  will  probably  require  much  less  than  2"  expansions  if  combined 
with  an  effective  pattern  matching  algorithm  which  checks  for  equivalence  at  each  node 
expansion.  (This  is  why  Prolog  is  so  beneficial;  its  entire  operation  is  based  on  pattern 
matching.) 

Boole’s  expansion  can  be  stated  for  n  variables  as  follows  (6:36): 

Theorem  1:  f(x\ ,  *2?  •  •  • , ®n)  4^  *i /"(0,  *2,  •  •  •  >  ®n)  d-  ®i./(l>  *^2>  •  •  • » ®n) 

A  complete  expansion  of  two  variables  is  the  following: 

f(x,y)  &  x'f(0,y)  +  xf(l,y) 

O  *'(2/7(0)  0)  +  yf( 0, 1))  +  *(2/7(1, 0)  +  yf(  1, 1)) 
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This  final  form  is  what  is  known  as  the  Minterm  Canonical  Form.  The  equivalence 
of  /  and  g  can  be  shown  (6:36-37)  by  the  following: 

Equation  1:  f(xux2,. .  &  g(xi,x2, . . 

iff 

Equation  2:  (^/(O,  *2,  •  •  •  >  ®n)  &  (x'i0(O,  *2>  •  •  • ,  *n) 

AND 

Equation  3:  (*i/(l,x2> •••,*«)  (xifir(l, x2, • . 

Boole’s  Expansion  can  then  be  recursively  applied  to  Equation  2  and  Equation  3  to 
produce  the  tree  in  Fig  4.1. 


Figure  4.1.  Boole’s  Expansion  AND-tree. 
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Since  the  search  space  is  an  AND-tree,  once  a  branch  is  found  to  be  false,  the  search 
can  terminate  with  failure.  A  blind,  depth-first  search  can  be  performed  by  simply  selecting 
the  first  variable  and  substituting  logical  Os  and  Is  for  it.  A  general  best-first  search 
technique  can  be  used  by  creating  some  criterion  for  the  best  variable  to  choose,  such  as 
most  occurrences  in  function  /  or  g  or  both.  Still,  in  the  worst  case,  the  tree  will  have 
to  expand  2  AND-nodes  at  each  level  to  a  depth  of  n  variables.  This  results  in  2"  -  1 
expansions,  but  in  most  cases,  due  to  pattern  matching  and  equivalence  checking  at.  each 
expansion,  fails  or  succeeds  much  faster. 

CPT  Dukes’s  code  has  been  modified  to  work  for  the  type  of  structures  used  in 
AFIT.VERIFY.  The  code  used  by  AFIT.VERIFY  will  now  be  summarized.  A  more 
detailed  discussion  is  provided  in  the  reference  (6:39-43). 

CPT  Dukes  defined  xor,  or,  and,  and  not  as  operators  represented  by  the  respective 
one-character  symbols  and  ".  In  AFIT.VERIFY,  xor,  or,  and,  and  neg  are  used  as 
principal  functors.  The  eval  clauses  are  Boolean  simplifications  of  the  functors  xor,  or, 
and,  and  neg. 


eval(or(l,_) , 1) :-! . 
eval(and(l,X) ,X) :-! . 
eval(xor(l,X) ,neg(X)) :-! . 
eval(or(0,X) ,X) :-! . 
eval(and(0,_) ,0) :-! . 
eval(xor(0,X) ,X) . 
eval(or(_,l) ,1) . 
eval(and(X,l) ,X) . 
eval(xor(X,l) ,neg(X)) :-! . 
eval(or(X,0) ,X) :-! . 
eval(and(_,0) ,0) . 
eval(xor(X,0) ,X) :-! . 
eval(neg(0),l):-!. 
eval(negCl) ,0) :-! . 
eval(or(neg(X) ,X) ,1) :-! . 
eval(or(X,neg(X)) ,1) . 
eval(and(neg(X) ,X) ,0) :-! . 
eval(and(X,neg(X)) ,0) . 
eval(xor(X,X) ,0) :-! . 
eval (xor (neg(X) ,X) ,1) :-! . 
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eval(xor(X,neg(X)) ,i) . 
eval(or(X,X) ,X) :-! . 
eval(and(X,X) ,X) . 
eval(X,X) :-! . 


The  extract  clauses  are  used  to  extract  a  variable  from  a  structure  to  use  in  the 
Boolean  expansion.  (These  currently  perform  a  blind,  depth-first  search.) 


extract(X,X)  /*  X  is  of  the  form  inX(Avariable)  */ 

X  L,Arg], 
var(Arg) , ! . 
extract (X,neg(Y)) 
extract (X,Y) . 
extract (X,or(L,_)) 
extract (X,L) . 
extract (X, or (_,R)) 
extract(X.R) . 
extract(X,and(L,_)) 
extract (X,L) . 
extract (X,and(_,R)) 
extract(X.R) . 
extract(X,xor(L,_)) 
extract (X,L) . 
extract (X,xor(_,R)) 
extract (X,R) . 


The  clauses  remove_x_l  and  remove jc_0  replace  every  occurrence  of  the  variable  x 
with  the  Boolean  value  1  and  0,  respectively.  The  two  clauses  are  identical,  except  for 
the  Boolean  value  replaced;  therefore,  it  is  only  necessary  to  include  one  of  the  clauses  for 
explanatory  purposes. 


remove_x_l(Y,X,Y) 
atomic (Y) , ! . 

remove_x_l(neg(Y) ,X,neg(Y))  : 
atomic (Y) , ! . 
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remove_x_l(Y,X,Y) 

Y  [Il.Argl], 
var(Argl) , 

X  [I2,Arg2],  /*  we  already  know  X  is  a  Variable  */ 

II  \««  12,!. 

reaove_x_l(neg(Y) ,X,neg(Y)) 

Y  *=..  [Il,Arg], 
var(Argl) , 

X  *..  [I2,Arg2],  /*  we  already  know  X  is  a  Variable  */ 

II  \»«  12,!. 
remove_x_ 1 ( Y ,  X ,  1 ) :  - 

Y  *..  [Il.Argl],  /*  inO(_i)  \==  in0(_2)  in  Prolog  */ 

var(Argl) ,  /*  but  we  know  it  is  the  same  input  */ 

X  =..  [Il,Arg2],!.  I*  we  already  know  X  is  a  Variable  */ 

remove_x_l(neg(Y) ,X,0) 

Y  *=..  [Il.Argl] , 
var(Argl) , 

X  *..  [Il,Arg2],!.  /*  we  already  know  X  is  a  Variable  */ 

remove_x_l(neg(Y) ,X,neg(NewY)) 

! ,remove_x_l(Y,X,NewY) . 
remove_x_l(or(L,R) ,X,or(LNew,RNew)> 

! , remove_x_ 1 (L , X , LNew) , 
remove.x. 1 (R , X , RNew) . 
remove_x_l(and(L,R) ,X, and (LNew, RNew)) 

! ,remove_x>l(L,X,LNew) , 
remove_x_l(R,X,RNew) . 
remove_x_l(xor(L,R) ,X,xor(LNew,RNew)) 

! ,remove_x_l(L,X,LNew) , 
remove_x_ 1 (R , X , RNew) . 

The  divide  clause  is  used  to  expand  the  clause,  F,  into  two  clauses,  one  where  every 
X  is  replaced  by  logical  0  and  the  other  where  every  X  is  replaced  by  logical  1.  The 
resulting  functions  are  then  simplified  by  the  evaluate_dukes  clauses. 


divide(F,X,FO,Fl) 

remove_x_0(F,X,F0Temp) , 
remove_x_l(F,X,FlTemp) , 
evaluate.. dukes (FOTemp.FO) , 
evaluate_dukes(FlTemp,Fl) . 
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evaluate.dukes (X.X) 
atomic (X) , ! . 
evaluate.dukes (X , X) : - 
X  [I,Arg], 
var(Arg) , 

I  \««  neg,! . 

evaluate.dukes (neg(F) .FReduced) 
evaluate.dukes (F ,FTemp) , 
aval (nog (FTamp) .FReduced) , ! . 
evaluate.dukes(or(L,R) .Resolved) 
evaluate.dukes (L.LNew) , 
evaluate.dukes (R.RNew) , 
eval(or(LNew,RNew) , Resolved) . 
evaluate_dukes(and(L,R) .Resolved) 
evaluate.dukes (L.LNew) , 
evaluate.dukes(R.RNew) , 
eval(and(LNew,RNev) .Resolved) . 
evaluate.dukes (xor(L.R) .Resolved) 
evaluate.dukes (L.LNew) , 
evaluate.dukes (R.RNew) , 
eval(xor(LNew.RNew) .Resolved) . 


The  eq  clauses  are  the  drivers  for  the  Boolean  expansion.  First,  the  eq  clauses  check 
for  trivial  equivalence  of  functions  F  and  G.  If  functions  F  and  G  are  not  equivalent ,  eq 
extracts  a  variable  X,  replaces  it  with  Is  and  Os  in  both  functions  F  and  G  to  produce  the 
new  functions,  FO,  Fl,  GO,  and  Gl.  The  process  is  then  repeated  on  the  new  functions. 
Checking  for  equivalence  at  each  stage  greatly  enhances  the  chance  of  producing  trivial 
equivalence  or  failure,  and  results  in  a  faster  search  than  performing  a  complete  Boolean 
expansion  and  then  checking  for  equivalence  only  once. 


eq(X.X) . 
eq(F,G) 
extract(X.F) , 
divide(F,X,FO,Fl) , 
divide (G.X, GO, Gl) , ! , 
eq(FO.GO) , ! , 
eq(Fl.Gl),!. 
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4.6  Summary 

AFIT_VERIFY  provides  a  framework  to  verify  any  type  of  hardware  module  (i.e., 
modules  with  multiple  outputs  and/or  multiple  states)  where  feedback  is  broken  by  a  reg¬ 
ister.  AFIT.VERIFY  was  developed  in  a  modular  fashion  to  allow  the  addition  of  new 
behaviors.  When  a  new  behavior  is  required,  only  derive_behavior,  evaluate_brown, 
and  replace-all  clauses  need  to  be  added.  No  modification  of  existing  code  should  be  re¬ 
quired.  The  portion  of  code  which  determines  the  equivalence  of  the  derived  outputs/states 
and  specified  outputs/states  will  need  to  be  expanded.  AFIT.VERIFY  currently  only  per¬ 
forms  simple  canonicalizations,  trivial  equivalence,  and  Boolean  expansion;  therefore,  only 
Boolean  or  simply  canonicalized  modules  can  be  verified.  All  code  was  developed  on  a 
PC  using  PROLOG-1,  since  this  provided  the  best  prototype  development  available  at  the 
time.  PROLOG-1  was  not  powerful  enough  to  verify  a  full-adder  module,  due  to  stack 
overflow.  Work  continued  on  mainframe  Quintus  Prolog,  which  had  no  problem  with  the 
full-adder  verification.  Future  work  at  AFIT  is  expected  to  be  performed  on  a  PC  version 
of  Quintus  Prolog. 


4-24 


V.  Results  and  Recommendations 


5.1  Results 

The  goal  of  this  thesis  was  to  provide  a  Prolog  implementation  of  the  concepts  dis¬ 
cussed  by  Barrow  (1).  AFIT.VERIFY  would  enable  an  AFIT  engineering  student  to 
describe  the  behavior  and  structure  of  a  logic  circuit.  AFIT.VERIFY  would  then  derive  a 
behavioral  description  from  the  structural  description  and  determine  if  the  two  behavioral 
descriptions  are  equivalent.  This  goal  has  been  met.  An  AFIT  engineering  student  can 
describe,  in  Prolog,  combinational  and  sequential  logic  circuits  composed  of  nand2,  xor, 
full-adder,  mux,  inc,  reg,  and  counter  modules.  Behavior  must  be  specified  by  using 
NAND,  XOR,  full-adder,  AND,  OR,  neg,  inc,  MUX,  reg,  and  counter  structures  in  Prolog 
functor  notation  as  shown  in  in  the  examples  in  Appendix  A.  The  circuit  descriptions 
currently  created  are  the  following; 

1.  nand2  -  A  two  input  NAND  gate  (Primitive  component). 

2.  xor  -  A  two  input  XOR  gate  composed  of  nand2  submodules. 

3.  f  addxor  -  A  full-adder  composed  of  xor  and  nand2  submodules. 

4.  mux  -  A  2X1  multiplexer  (Primitive  Component). 

5.  reg  -  A  register  which  stores  an  integer  (Primitive  Component). 

6.  inc  -  An  integer  incrementer  (Primitive  Component). 

7.  counter  -  An  integer  counter  composed  of  mux,  reg,  and  inc  submodules. 

Two  non-primitive  modules,  the  counter  and  f  addxor  modules  have  been  verified  using 
AFIT.VERIFY.  Sample  runs  are  included  as  Appendix  B.  The  counter  module  provides 
an  example  of  a  simple  sequential  circuit.  The  counter  module  is  composed  entirely  of 
primitive  components,  but  demonstrates  AFIT.VERIFY’s  ability  to  treat  a  circuit  as  a 
black-box.  The  behavior  of  the  external  state  count  is  derived  by  deriving  the  state  of 
its  internal  representation,  the  contents  of  the  register.  Then,  count  is  substituted  for 
contents  wherever  it  may  appear  in  the  derived  behavior.  The  counter  module  was 
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verified  on  PROLOG-1  and  Quintus  Prolog.  Two  versions  of  AFIT.VERIFY  were  used. 
One  version  contains  outputs  which  helped  in  debugging  the  development  code.  The  second 
version  removed  all  ouputs  to  show  how  much  time  is  devoted  to  I/O.  The  results  for  the 
counter  and  faddxor  modules  are  summarized  in  Table  5.1. 


Table  5.1.  PROLOG-1  vs.  Quintus  Prolog  Run  Times 


Module 

PROLOG-i 

Quintus  Prolog 

count er (outputs ) 

ll.Osec 

counter (no  outputs) 

5.0sec 

f  addxor (outputs) 

175.0sec 

13.0sec 

faddxor (no  outputs) 

83.0sec 

7.0aec 

Quintus  Prolog  was  much  faster,  as  expected.  The  times  are  encouraging  for  further 
work.  The  faddxor  module,  as  specified,  contains  11  primitive  gates  (nand2).  This  is 
not  a  significant  number  of  gates,  but  it  requires  the  hierarchical  verification  of  the  xor 
module  in  the  process  of  verifying  the  faddxor  module.  The  derivation  ultimately  contains 
30  connections;  12  from  the  faddxor  specification  and  9  each  from  the  2  xor  specifica¬ 
tions.  Though  not  overwhelming  evidence,  it  suggests  that  circuits  with  1000  structural 
connections  could  be  verified  in  a  few  minutes.  The  AFIT.VERIFY  methodology  is  defi¬ 
nitely  deserving  of  more  research.  It  should  be  noted  that  the  faddxor  module  could  not 
be  verified  by  PROLOG-1  with  the  “output”  version  of  AFIT.VERIFY.  This  was  due  to 
insufficient  stack  space. 

Currently,  all  modules,  submodules,  and  the  verification  code  need  to  be  loaded 
in  the  order  specified  in  Appendix  A  prior  to  verification  of  a  module.  The  types  of 
modules  which  should  exist  as  primitives  and  be  loaded  with  the  verification  code  will 
need  to  be  determined  in  follow-on  work.  Since  the  examples  were  sufficiently  small  for 
mainframe  Quintus  Prolog,  no  system  state  (verified,  derived-behavior,  next_state 
clauses)  had  to  be  written  to  disk  for  possible  system  restart  (1:487).  When  larger  circuits 
(1000  internal  connections)  are  verified,  a  method  for  saving  system  state  and  restarting 
verification  from  that  point  will  be  required.  Prolog  does  provide  built-in  mechanisms  to 
perform  state  savings  during  the  course  of  a  program. 
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Each  Prolog  clause  was  developed  and  tested  modularly  by  first  ensuring  the  proper 
operation  of  each  subclause  and  then  testing  each  clause.  The  majority  of  the  code  was 
developed  in  a  three  month  period.  The  code  is  not  verified,  but  each  clause  does  provide 
the  expected  behavior.  When  AFIT.VERIFY  claims  that  a  module  is  verified,  it  can  be 
trusted.  AFIT.VERIFY  provides  AFIT  with  a  method  to  provide  true  module  verification. 
AFIT.VERIFY  is  only  a  start  towards  a  complete  design/verification  system,  but  work 
towards  such  a  system  will  continue  at  AFIT.  This  research  should  result  in  great  time 
and  cost  savings  to  AFIT  and  possibly  to  the  rest  of  the  engineering  community. 

5.2  Recommendations 

Many  different  areas  can  be  researched  in  follow-on  efforts.  The  following  is  only  a 
suggested  list. 

1.  Verification  of  Gordon’s  D74  (1:456)  or  other  larger  circuit. 

2.  In  conjunction  with  the  AFIT  VLSI  group,  integration  of  AFIT.VERIFY  into  a 
larger  design  system  similar  to  Grabowiecki  et  al.  (10)  . 

3.  Integration  into  AFIT.VERIFY  of  a  Very  High  Speed  Integrated  Circuit  (VHSIC) 
Hardware  Description  Language  (VHDL)  to  Prolog  parser  for  the  construction  of 
Prolog  behavioral  and  structural  specifications  .  (A  VHDL  to  Prolog  parser  exists 
on  the  AFIT  Microvax  Cub  under  the  directory,  ”ges/MCNC/vhdl2.) 

4.  Analysis  of  Prolog  vs  HOL  or  Prolog/HOL  hybrid  approach. 

The  first  thing  to  consider  before  any  of  these  areas  can  be  researched  is  the  viability 
of  a  Prolog  approach.  The  specifications,  structural  and  behavioral,  required  for  small 
circuits  are  small,  but  the  size  of  a  structural  specification  is  a  function  of  the  number 
of  connections,  or  connected  facts.  If  behavior  and  structural  equivalence  (i.e.  low-level 
behavioral  specification)  can  be  modelled  at  the  gate  level,  and  it  should  be,  a  Prolog  ap¬ 
proach  appears  feasible.  This  feasibility  is  based  on  the  Quintus  Prolog  run  times  discussed 
above.  If  all  connections  are  required  at  the  transistor  level,  then  it  could  take  years  to 
verify  a  large  circuit  using  Prolog. 
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Another  problem  is,  “  What  is  behavior,  and  how  can  it  be  specified?”  It  is  straight¬ 
forward  for  a  combinational  logic  circuit  composed  of  standard  gates.  But  how  does  one 
represent  a  sequential  circuit  with  feedback  not  broken  by  a  state  variable.  This  problem 
is  expected  to  be  studied  in  the  next  thesis  cycle. 

After  consultation  with  the  AFIT  VLSI  group,  it  appears  that  future  research  should 
proceed  as  follows:  Obtain  a  circuit  from  the  AFIT  VLSI  group  containing  100  to  200 
connections.  Verify  this  circuit  using  AFIT.VERIFY,  adding  the  appropriate  behavioral 
constructs  common  to  the  AFIT  VLSI  group.  (This  will  be  performed  in  the  next  thesis 
cycle.)  If  this  proves  successful  (i.e.,  verification  requires  minutes  as  opposed  to  hours),  a 
larger  (more  than  1000  connections)  circuit  should  be  identified  for  verification.  Integral  to 
this  phase  should  be  the  incorporation  of  the  previously  mentioned  VHDL  to  Prolog  parser. 
This  would  provide  the  AFIT  VLSI  group  with  the  capability  to  use  the  DoD-mandated 
IIDL.  Integration  of  the  Prolog  verifier  into  a  larger  VLSI  design  system  should  be  the 
ultimate  goal,  but  some  verification  capability  is  preferred  to  no  verification  capability. 
The  ability  to  verify  portions  of  a  large  circuit  can  provide  an  increased  capability  to  the 
VLSI  group.  One  must  also  remember  that  AFIT.VERIFY  is  a  hierarchichal  verification 
system.  Verification  of  one  module  of  the  circuit  at  a  time  is  the  method  used  to  speed  up 
the  verification  process.  It  is  also  the  method  which  should  be  used  in  further  developing 
the  system. 
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Appendix  A.  AFITJVERIFY  Code 


The  following  files  constitute  the  development  code  for  AFIT.VERIFY.  The  major¬ 
ity  of  code  was  developed  using  PROLOG-1.  The  only  differences  in  PROLOG-1  and 
Quintus  Prolog  code  are  handled  in  the  two  separate  files  qops.pro  (Quintus)  and  ops.pro 
(PROLOG-1).  All  other  files  remain  the  same  on  both  systems.  The  files  developed  for 
AFIT.VERIFY  are  the  .ollowing: 

1.  qops.pro  -  Quintus  Prolog  operator  definitions  and  system-dependent  procedures. 

2.  ops.pro  -  PROLOG- 1  operator  definitions  and  system-dependent  procedures. 

3.  boole2.pro  -  CPT  Duke’s  Modified  Boolean  Expansion  code. 

4.  eval.pro  -  Rudimentary  canonicalization  clauses. 

5.  derbeh.pro  -  Derive  Module  behavior. 

6.  derstate.pro  -  Derive  Module  next  state. 

7.  eqbeh.pro  -  Determine  Behavior  Equivalence. 

8.  verify.pro  -  Driver  clause. 

9.  counter.pro  -  Counter,  Incrementer,  Register,  and  Multiplexer  Module  specifications. 

10.  xor.pro  -  Exclusive-OR  and  NAND  Module  specifications. 

11.  faddxor.pro  -  Full  Adder  Module  specification. 

For  use  in  MgX,  the  .pro  files  were  slightly  modified  and  changed  to  .tex  files.  The  .pro 
files  were  given  to  Dr.  Brown  on  a  b\n,  360 K  floppy  disk  and  also  appear  on  the  AFIT 
Microvax  System  Cub  under  'ksparks\thesis. 
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/***>m************************************>m***************  */ 
/*  QOPS.PRO  */ 
/*  This  file  provides  the  utility  and  operator  definitions  */ 
/*  to  run  verify. pro  on  Quintus  Prolog.  The  :-  multifile  */ 
/*  definition  was  required  to  allow  Modules  to  be  declared  */ 
/*  in  separate  .pro  files.  Without  this  definition,  any  */ 
/*  new  module  loaded  would  wipe  out  the  previously  loaded  */ 
/*  modules,  and  in  the  case  of  a  fuiladder  (multiple  file)  */ 
/*  this  was  a  problem  (the  defn  of  nand2  and  xor  was  gone)  */ 
/*  Operator  precedence  in  Quintus  goes  from  0-1200,  but  */ 
/*  PROLOG-1  runs  0-255  ,  PROLOG-1  refman  5.5,  Bratko  p.182  */ 
/*  */ 
/*******>M***************************************************/ 


:-  multifile  module_name/l,  port/4,  part/3,  output.eqn/2 ,  state_eqn/2, 
state_map/3,  state_of/3,  connected/3. 

/* - - UTILITIES . */ 

writeln(D) 

nl. 

writeln([X|Rest]) 
write (X) , 
writeln(Rest) . 

/**********  >M**>M*>MiM*******************************************/ 


/*  */ 

/*  The  goal  ’find_all(T,G,L) '  constructs  a  list  L  consisting  */ 

/*  of  all  instantiations  of  the  term  T  for  which  the  goal  G  */ 

/*  is  satisfied.  The  goal  */ 

/*  find_all([X,wife_of ,Y] ,  husband (Y,X) ,  Couples)  ,  */ 

J*  for  example,  might  instantiate  Couples  to  */ 

/*  [[amy,wife_of , tony] , [sue, wife.of , john] , [dot, wife.of, tom]]  */ 

/*  for  a  given  family-database.  See  the  Bratko  text,  p.  177,  */ 

/*  for  another  implementation  of  ’find. all ’ .  */ 

I*  */ 

/*  FIND.ALL  is  needed  to  check  for  proper  operation  of  the  */ 

/*  clauses  verif y.components ,  derive.and.equate.behaviors,  and  */ 

/*  derive.and.equate.states .  */ 

/* - - - . */ 

f ind_all(T,G,L)  :-  /*  To  make  a  list  L  of  terms  T  */ 

store. elts (T, G) ,  /*  satisfying  the  goal  G,  store  */ 

build_list(D ,L) .  /*  the  terms  as  facts  and  then  */ 

/*  collect  the  facts  in  am  */ 

/*  initially-erapty  list.  */ 
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store_elts(T,G)  /*  ’store(T.G)’  has  the  side-  */ 

asserta(element(end)),  /*  effect  of  forming  a  sequence  */ 

call(G),  /*  of  facts  having  the  form  */ 

asserta(element (T) ) ,  /*  ’  element (T) » ,  where  T  is  a  */ 

fail*  /*  term  satisfying  the  goal  G.  */ 

store.eltsL,.) .  /*  The  second  clause  enables  */ 

/*  the  procedure  to  succeed.  */ 

build.list (Part, Total)  /*  ’build_list(P,Q) ’  succeeds  */ 

get.next(T),  /*  in  case  Q  is  the  list  re-  */ 

•' »  /*  resulting  from  attaching  the  */ 

build_list([T | Part] .Total).  /*  ’element’  facts  in  the  cur-  */ 

build_list(L,L) .  /*  rent  database  to  the  list  P.  */ 


get .next (T)  :- 
retract (element (T) ) , 

•  > 

T  \==  end. 

length.of (□  ,0) .  /*  Bratko,  p.  88  */ 

length. of ([.I L] ,N)  :- 
length.of (L,N1) , 

N  is  HI  +  i. 


member(X,[X|_]).  /*  Bratko,  p.  68  */ 

member(X,[_lL])  j- 
member(X.L) . 

undup (□,□).  /*  The  null  list  contains  no  */ 

undup([X|T],M)  :-  /*  duplication.  If  X  is  in  the  */ 

member (X,T),  /*  tail,  then  remove  all  dups  from  */ 

'  »  /*  the  tail .  If  X  is  not  in  the  */ 

undup (T,M) .  /*  tail,  return  X  with  other  dups  */ 

undup([X|T] , [X|M])  :-  /*  removed  from  the  tail.  */ 

undup (T,M) . 


/*>M********************************************************/ 


/*  */ 

/*  SET.OF  performs  the  same  function  as  FIND. ALL,  except  */ 

/*  all  duplicates  are  removed  from  the  list  L.  SET.OF  is  */ 

/*  not  defined  in  PROLOG-1  but  SETOF  is  defined  in  */ 

/*  However;  since  SETOF  didn't  perform  as  expected,  the  */ 

/*  clause  SETOF  is  also  used  in  QUINTUS  PROLOG.  */ 

/*  */ 

/*  The  above  utilities  member(X,L)  and  undup(L.UL)  are  */ 

/*  required  to  produce  set.of (T,G,UL) .  The  member(X,L)  */ 

/*  clause  determines  if  X  is  a  member  of  list  L.  The  */ 

/*  undup(L.UL)  clause  removes  duplicates  from  list  L  to  */ 

/*  produce  list  UL.  */ 

/*  */ 


/***********************************************************/ 
set.of (T,G,UL) 
find_all(T,G,L) , 
undup(L,UL) . 


/* - OPERATORS . */ 

?-  unknown (trace, f ail) . 

?-  op (100,  fy,  not). 

not  X 

call (X),! .fail; 
true. 

?-  op (900,  xfx,  :=). 

?-  op (800,  fx,  if). 
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/***********************************************************/ 
/*  OPS. PRO  */ 

/*  This  file  provides  the  utility  and  operator  definitions*/ 
/*  to  use  verify. pi.*o  in  Prolog-1.  Remember,  in  Prolog-1  */ 
/*  operator  precedence  runs  from  0  to  255.  */ 

/*********************>m************************************/ 

/* . UTILITIES . */ 

writeln(d)  :- 
nl. 

writeln([X|Rest])  :- 
write (X) , 
writeln(Rest) . 


/********>m******************************************************/ 


/*  */ 

/*  The  goal  ’f ind_all(T,G,L) ’  constructs  a  list  L  consisting  */ 

/*  of  all  instantiations  of  the  term  T  for  which  the  goal  G  */ 

/*  is  satisfied.  The  goal  */ 

/*  find_all([X,wife_of ,Y] ,  husband(Y.X) ,  Couples)  ,  */ 

/*  for  ex?  ^ple,  might  instantiate  Couples  to  */ 

/*  [[amy,wife_of , tony] , [sue,wife_of , john] , [dot, wife_of, tom]]  */ 

/*  for  a  given  family-database.  See  the  Bratko  text,  p.  177,  */ 

/*  for  another  implementation  of  ’find.all’ .  */ 

/*  */ 

/*  FIND.ALL  is  needed  to  check  for  proper  operation  of  the  */ 

/*  clauses  verif y.components ,  derive_and_equate_behaviors,  and  */ 

/*  derive_and_equate_states .  */ 

/* . - . */ 


find_all(T,G,L)  :- 

/*  To  make  a  list  L  of  terms  T 

*/ 

store_elts(T,G) , 

/*  satisfying  the  goal  G,  store  */ 

build_list([] ,L) . 

/*  the  terms  as  facts  and  then 

*/ 

/*, collect  the  facts  in  an 

*/ 

/*  initially- empty  list. 

*/ 

store_elts(T,G)  :- 

/*  ’store(T,G)’  has  the  side- 

*/ 

assert a (element (end)) , 

/*  effect  of  forming  e.  sequence 

*/ 

call(G) , 

/*  of  facts  having  the  form 

*/ 

asserta(element(T)) , 

/*  ’ element (T) ' ,  where  T  is  a 

*/ 

fail. 

/*  term  satisfying  the  goal  G. 

*/ 

store_elts(_,_) . 

/*  The  second  clause  enables 

*/ 

/*  the  procedure  to  succeed. 

*/ 
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build.list (Part, Total) 
get.next(T) , 

i 

•  I 

build.list ( [T | Part] .Total) . 
build.list (L,L). 

get .next (T) 
retract ( element (T) ) , 

i 

*  » 

T  \==  end. 

length. of ( □  , 0) .  /*  Bratko,  p.  88  */ 

length.of ( [_ | L] ,N) 
length.of (L,N1) , 

N  is  N1  +  1. 


member  (X,  [X|J).  /*  Bratko,  p.  68  */ 

member (X, [_ | L]) 
member(X,L) . 

undup  (□,[]).  /*  The  null  liBt  contains  no  */ 

undup( [X|T] ,M)  /*  duplication.  If  X  is  in  the  */ 

member(X,T),  /*  tail,  then  remove  all  dups  from  */ 

•»  /*  the  tail.  If  X  is  not  in  the  */ 

undup(T,H).  /*  tail,  return  X  with  other  dups  */ 

undup([X|T] , [X|M])  /*  removed  from  the  tail.  */ 

undup (T,M) . 


/*  ’build_list(P,Q) ’  succeeds  */ 
/*  in  case  Q  is  the  list  re-  */ 
/*  resulting  from  attaching  the  */ 
/*  'element*  facts  in  the  cur-  */ 
/*  rent  database  to  the  list  P.  */ 
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/t*****^*********^*****************************************/ 


I*  */ 
/*  SET.OF  performs  the  same  function  as  FIND. ALL,  except  */ 
/*  all  duplicates  are  removed  from  the  list  L.  SET. OF  */ 
/*  is  not  defined  in  PROLOG-1  but  is  defined  in  QUINTUS  */ 
/*  PROLOG.  */ 
/*  */ 
/*  The  above  utilities  member (X,L)  and  undup(L.UL)  are  */ 
/*  required  to  produce  set.of (T,G,UL) .  The  member (X,L)  */ 
/*  clause  determines  if  X  is  a  member  of  list  L.  The  */ 
/*  undup(L.UL)  clause  removes  duplicates  from  list  L  to  */ 
/*  produce  list  UL.  */ 
/*  */ 


/>m*********************************************************/ 
set.of (T,G,UL) 
find. all (T,G,L) , 
undup(L.UL) . 

f+ . OPERATORS . */ 

?-  op (200,  xfx,  :=). 

?-  op (190,  fx,  if). 
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/**********************************************************/ 


/*  */ 

/*  BOOLE’S  EXPANSION  */ 

/*  */ 

/*  The  following  code  is  a  modified  version  of  code  */ 

/*  developed  by  CPT  Mike  Dukes.  */ 

/*  */ 

/*  He  defined  xor,  or,  and,  and  not  as  the  respective  */ 
/*  operators,  $,  C,  “,  and  I  use  xor,  or,  and,  and  */ 
/*  neg  as  principal  functors.  */ 

/*  A  detailed  explanation  of  this  code  can  be  found  in  */ 
I*  CPT  Dukes’s  PhD  Prospectus,  “Formal  Verification  */ 

/*  Using  VHDL’’.  Additional  in-line  comments  are  */ 

/*  provided  where  modification  for  this  approach  is  */ 

/*  required.  */ 

/*  *1 


/**********************************************************/ 

eval(or(l,_) ,1) :-! . 
eval(and(l,X) ,X) :-! . 
eval(xor(l,X),neg(X)):-! . 
eval(or(0,X),X) :-! . 
eval(and(0,_) ,0) :-! . 
eval(xor(0,X) ,X) :-! . 
eval(or(_,l) ,1) . 
eval(and(X,l) ,X) :-! . 
eval(xor(X,l) ,neg(X)) . 
eval(or(X,0) ,X) . 
eval(and(_,0) ,0) :-! . 
eval(xor(X,0) ,X) :-! . 
eval(neg(0) ,1) :-! . 
eval(neg(l) ,0) . 
eval(or(neg(X) ,X) ,1) :-! . 
eval(or(X,neg(X)) ,1) :-! . 
eval(and(neg(X) ,X) ,0) :-! . 
eval(and(X,neg(X)) ,0) :-! . 
eval(xor(X,X) ,0) :-! . 
eval(xor(neg(X) ,X) ,1) :-! . 
eval(xor(X,neg(X)) ,1) :-! . 
eval(or(X,X) ,X) :-! . 
eval(and(X,X) ,X) :-! . 
eval(X,X) :-! . 


/*  X  is  of  the  form  inX(Avariable)  *1 


extract (X,X) 

X  *. .  L.Arg]  , 
var(Arg) , ! . 
extract(X,neg(Y)) 
extract (X,Y) . 
extract (X, or (L,_)) 
extract (X.L) . 
extract(X,or(_,R)) 
extract (X,R) . 
extract(X,and(L,_)) 
extract (X.L) . 
extract (X, and (_,R)) 
extract (X,R) • 
extract(X,xor(L,_)) 
extract (X,L) . 
extract (X,xor(_,R)) 
extract (X,R) . 


remove..x_l(Y,XfY) 
atomic (Y) , ! . 

remove_x_l(neg(Y) ,Xfneg(Y)) 
atomic (Y) , ! . 
remove„x_l(Y,X,Y) 

Y  .  [Il.Argl], 

var(Argl), 

X*..  [I2,Arg2], 

II  \«*  12,!. 

remove_x_l(neg(Y) ,X,neg(Y)) 

Y  .  [Il.Arg], 

var(Argl) , 

X  .  Cl2,Arg2], 

II  \==  12.!. 
r emove_x_ 1 ( Y , X , 1 ) : - 

Y  *..  [Il.Argl], 
var(Argl) , 

X  =. .  [Il,Arg2] , ! . 
remove_x_l(neg(Y) ,X,0) 

Y  *..  [Il.Argl], 
var(Argl) , 

X  =. .  [Il,Arg2] , ! . 
remove.x.KnegCY)  .X.neg(KewY)) 

!  remove_x_l(Y,X,NewY) . 
remove_x_ 1 (or (L , R) , X , or (LNev , RNew) ) 
! ,remove_x_l(L,X,LNew) , 
remove_x_l(R,X,RNew) . 


/*  we  already  know  X  is  a  Variable  */ 


/*  we  already  know  X  is  a  Variable  */ 


/*  inO(_l)  \==  in0(_2)  in  Prolog  */ 
/*  but  we  know  it  is  the  same  input  */ 
/*  we  already  know  X  is  a  Variable  */ 


/*  we  already  know  X  is  a  Variable  */ 
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r emove_x_ 1 ( and (L ,  R) ,  X , and (LNew.RNew))  : - 
! ,remove_x_l(L,X,LNew) , 
remove_x_l(R,X,RNew) . 
remove_x_l(xor(L,R) ,X,xor (LNew.RNew)) 

! ,remove_x_l(L,X,LNew) , 
remove_x_l(R,X,RNew) . 

remove_x_0(Y,X,Y) 
atomic (Y) , ! . 

remove_x_0(neg(Y) ,X,neg(Y)) 
atomic (Y) , ! . 
remove_x_0(Y,X,Y) 

Y  *. .  [Il.Argl] , 
var(Argl) , 

X  *..  [I2,Arg2],  /*  ve  already  know  X  is  a  Variable  */ 

II  \==  12,!. 

remove_x_0(neg(Y) ,X,neg(Y)) 

Y  .  [Il.Argl] , 
var(Argl) , 

X  =  ..  [I2,Arg2],  /*  we  already  know  X  is  a  Variable  */ 

II  \=*  12.!. 
remove_x_0(Y,X,0) 

Y  *..  [Il.Argl], 
var(Argl) , 

X  *..  [Il,Arg2],!.  /*  we  already  know  X  is  a  Variable  */ 

remove_x_0 (neg (Y) , X , 1 ) : - 

Y  =. .  [Il.Argl], 
var(Argl) , 

X  =..  [Il,Arg2],!.  /*  we  already  know  X  is  a  Variable  */ 

remove_x_0(neg(Y) .X.neg(NewY)) 

! ,remove_x_0(Y.X.NewY) . 
remove_x_C(or(L,R) .X.or(LNew.RNew)) 

! ,remove_x«0(L,X,LNew) , 
remove_x_0(R.X.RNew) . 
remove_x_0(and(L,R) ,X, and (LNew.RNew)) 

! ,remove_x_0(L,X,LNew) , 
remove_x_0(R,X,RNew) . 
remove_x_0(xor(L.R) .X.xor(LNew.RNew)) 

! ,remove_x_0(L,X,LNew) , 
remove_x_0(R,X,RNew) . 


divide (F,X,FO, FI) 
remove_x.O(F,X,FOTemp) , 
remove.x_i(F,X,FlTemp) , 
evaluate.dukes (FOTemp , FO) , 
evaluate.dukes(FlTemp.Fl) . 


evaluate.dukes (X.X) 
atomic (X) , ! . 
evaluate_dukes(XtX) 

X  =..  [I.Arg], 
var(Arg) , 

I  \==  neg, ! . 

evaluate.dukes (neg(F) .FReduced)  : 
evaluate_dukes(F,FTemp) , 
eval(neg(FTemp) .FReduced) , ! . 
evaluate.dukes (or (L.R) .Resolved) 
evaluate.dukes(L.LNew) , 
evaluate.dukes(R.RNew) , 
eval(or(LNew,RNew) .Resolved) . 
evaluate.dukes (and (L.R) .Resolved) 
evaluate.dukes (L.LNev) , 
evaluate.dukes(R.RNew) , 
eval(and(LNev,RNew) .Resolved) . 
e valuate_dukes(xor (L, R) .Resolved) 
evaluate.dukes (L.LNew) , 
evaluate_dukes(R,RNev) , 
eval(xor(LNew,RNew) .Resolved) . 


eq(X,X) . 
eq(F.G) 
extract (X.F) , 
divide(F.X.FO.Fl) , 
divide(G.X.GO.Gl) , ! , 
eq(FO.GO) , ! , 
eq(Fl.Gl) , ! . 


/*  EVAL.PRO  */ 
/*  This  file  performs  a  rudimentary  simplification  and  */ 
/*  and  canonicalization  on  behavioral  structures.  */ 
/*  Any  new  behavioral  structures  added  will  require  */ 
/*  additional  evaluate.brown  clauses.  */ 
/*  */ 


/***>M****4^************************************************/ 

evaluate!. (X, EX) 

writeln( [’Value  of  ’,X, 
evaluate_brown(X,EX) , 
writeln([’  ’,EX]). 


/*  */ 

/*  The  first  three  clauses  provide  basis  cases  for  a  */ 

/*  behavioral  structure,  namely  a  Variable,  Atom,  or  an  */ 
/*  elementary  structure.  */ 

/*  */ 


/***********************************+***********************/ 

evaluate_brown(X,X) 
var(X) , ! . 

evaluate_brown(X,X) 
atomic (X) , ! . 

evaluate_brown(Struct, Struct) 

Struct  [F,Arg] , 

(  var(Arg)  ;  atom(Arg)  ),!. 
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/***********************************  **********************/ 
/*  */ 

/*  The  next  three  clauses  provide  a  method  of  simplifying  */ 
/*  and  canonicalizing  the  boolean  functions  and,  or,  */ 

/*  and  negation.  Another  canonical  form  may  prove  quicker  */ 
/*  and  these  clauses  would  need  to  be  modified  accordingly.*/ 
/*  */ 

/*  NOTE:  neg  has  been  chosen  as  the  negation  functor,  as  */ 
/*  opposed  to  the  more  widely  used  not,  since  Prolog-1  */ 
/*  defines  not  as  the  absence  of  a  fact.  The  functor  not  */ 
/*  is  not  provided  in  Pure  Prolog  and  therefore,  does  not  */ 
/*  exist  in  Quintus  Prolog.  This  is  why  I  have  defined  not*/ 
/*  in  the  qops.pro  file.  */ 

/*  */ 

/************************************************************/ 

evaluate_brown(and(X,Y) .Value) 
evaluate_brown(X,EX) , 
evaluate.brown ( Y , EY) , 

(  (EX  «  0  ;  EY  ■  0) ,  ! , 

Value  *  0 

EX  *  1,  ! , 

Value  *  EY 

> 

EY  «  1,  ! , 

Value  *  EX 

I 

!, Value  *  and(EX.EY) 

). 

evaluate_brown(or(X,Y) .Value) 
evaluate_brown(X,EX) , 
evaluate_brown(Y,EY) , 

(  (EX  «  1  ;  EY  «  1),  !, 

Value  *  1 

» 

EX  *  0,  ! , 

Value  =  EY 

9 

EY  -  0,  ! , 

Value  =  EX 

> 

!, Value  =  or(EX,EY) 

). 
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evaluate_brown(neg(X) .Value) 
evaluate_brown(X,EX) , 

(  var(EX) ,  ! , 

Value  *  neg(X) 

I 

EX  «  0,  ! , 

Value  =  1 

* 

EX  -  1,  ! . 

Value  *  0 
i 

atom(EX) ,  ! , 

Value  *  neg(EX) 

I 

EX  -  neg(N) ,  ! . 

Value  «=  N 

9 

EX  *  and(Al.A2) ,  ! , 

evaluate_brown(neg(Al) ,NA1) , 
evaluate_brown(neg(A2) ,NA2) , 
Value  *  or(NAl,NA2) 

9 

EX  »  or (01, 02) ,  !, 
evaluate_brown(neg(01) ,N01) , 
evaluate_brown(neg(02) ,NQ2) , 
Value  *  and(N01,N02) 

9 

! .Value  *  neg(EX) 
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/************************************************************/ 
/*  */ 

/*  The  remaining  clauses  provide  a  method  of  simplification*/ 
/*  and  canonicalization  of  the  functions  required  to  verify*/ 
/*  the  fulladder  and  counter,  namely,  if  and  +.  */ 

/*  */ 

/ft***********************************************************/ 


evaluate.brown ( if (Cond , Texp , Fexp) .Value ) 
evaluate_brown(Cond, NCond) , 
evaluate_brown(Texp,NTexp) , 
evaluate_brovn(Fexp,NFexp) , 

(  (  NCond  =  i,  ! , 

Value  *  NTexp  )  ; 

(  NCond  *  0,  !, 

Value  =  NFexp  )  ; 

(  NTexp  =  NFexp,  ! ,  /' 

Value  *  NTexp  )  ; 

Value  *  if (NCond, NTexp, NFexp) , ! ) . 


/*  Condition  is  true  */ 
/*  return  True  exp  */ 
/*  If  False  then  */ 
/*  return  False  exp  */ 
Condition  irrelevant  */ 
/*  if  choices  equal  */ 
/*  otherwise  return  */ 


/*  simplified  expression.  */ 


evaluate_brown(X+Y,Z) 
integer (X) , 
integer (Y) ,  !, 

Z  is  X  +  Y.  /*  force  simplification  of  1  +  2  =  3  */ 


evaluate_brown(X+Y,Z) 

integer (Y), ! ,  /*  X  not  integer  due  to  cut  */ 

evaluate_brovn(X,NewX) , 

Z  «  Y  +  NewX.  /*  canonicalize  with  integer  first  */ 

evaluate_brown(X+Y,Z) 

! ,evaluate_brown(X,NewX) , 
evaluate_brown(Y,NewY) , 

Z  =  NewX  +  NewY. 

evaluate_brown(X,X) .  /*  default  simplification  for  complex  */ 

/*  structures  like  in(incA(X)).  */ 
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/************************************************************/ 


/*  Derive.Behaviors  */ 
/*  *1 
/*  The  two  derive.behaviors  clauses  identify  a  specific  */ 
/*  output  for  the  Module.  The  derive.behavior  clauses  */ 
/*  are  then  invoked  to  derive  the  behavior  of  that  output  */ 
/*  for  this  particular  Module.  */ 
/*  The  derive.behavior  clause  uses  the  part,  connected,  */ 
/*  and  output. eqn  clauses  to  derive  an  output's  behavior  */ 
/*  and  tie  it  to  this  instantiation  of  the  module  as  */ 
/*  described  in  the  in-line  comments  to  follow.  */ 
/*  The  derive.and.equate.behaviors  clause  in  verify. pro  */ 
/*  uses  derive.behaviors  to  derive  all  Module  outputs  and  */ 
/*  determine  their  equivalence  to  the  specified  output.  */ 
/*  The  arguments  for  derive.behaviors  and  derive.behavior*/ 
/*  have  the  following  meanings:  */ 
/*  */ 
/*  Args:  Module:  e.g.,  'xor' ,  ’nand.2' ,  ...  */ 
/*  Form:  A  formula  involving  terminal-behavior.  */ 
/*  In  the  initial  query,  this  may  be  */ 
/*  something  like  'out(X)'.  */ 
/*  Behavior:  The  resulting  derived  behavior.  */ 
/*  In  the  present  version  of  this  procedure,  it  is  assumed  */ 
/*  that  all  of  the  component-parts  of  Module  have  been  */ 
/*  previously  verified  by  verif y.components .  The  verified  */ 
/*  components  derived  behavior  is  either  asserted  in  a  */ 
/*  derived.behavior  clause  or  specified  in  an  output.eqn  */ 
/*  if  the  component-part  is  a  primitive.  */ 
/*  */ 


/************************************************************/ 


derive.behaviors (Module, Form, Behavior)  :-  /*  no  state  */ 

not  state_eqn(Module,_) , ! , 
output_eqn(Module,Form  :«  Spec.Behavior) , 
derive.behavior (Module , Form .Behavior) . 
derive.behaviors (Module, Form, Behavior)  :-  /*  has  state  (!),  */ 

output.eqn (Module, Form  :«  Spec.Behavior), 
derive.behavior (Module , Form , TBehavior ) , 

substitute.state (Module, TBehavior, Behavior) .  /*  might  require  the  */ 

/*  removal  of  some  internal  variables.  */ 
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/**************************4^*********************************/ 

/*  Rules  1A  and  IB  derive  behavior  if  Form  is  the  name  of  a  */ 
/*  terminal  to  which  some  other  terminal,  in  Module,  is  */ 
/*  connected.  Rule  1A  is  invoked  if  the  other  terminal  is  a  */ 
/*  primary  terminal  in  Module,  i.e.,  one  of  its  inputB  or  */ 
/*  outputs.  Rule  IB  is  invoked  if  the  other  terminal  belongs  */ 
/*  to  one  of  Module's  component -parts.  */ 

/****%********************************************************/ 

derive.behavior (Module,  Form,  Source) 
connectedCModule,  Source,  Form), 
primary.source (Source) , ! , 
writeln( ['Applying  Rule  1A  to  '.Form]), 
derive.behavior (Module,  Form,  Behavior) 
connected(Module,  Source,  Form), 
derived.source (Source) , ! , 
writeln( [’Applying  Rule  IB  to  ',  Form]), 
derive.behavior (Module,  Source,  Behavior). 

/******++*****+*++*++**+++*++*+4t**+*****++++++++***+++**+++***/ 

/*  primary.source  and  derived  source  distinguish  between  a  */ 
/*  Module  input (primary.source)  and  a  Component  input  */ 

/*  (secondary.source) .  */ 

/****** ****4^************************ *************************/ 

primary.source (Source) 

Source*..  [_,Arg], 
var(Arg) . 

derived.source (Source) 

Source*..  L.Arg], 

Arg  *..  [_,Arg2] , 
var(Arg2) . 
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z****************************^*^******************************/ 

I*  Rule  2  is  invoked  it  Form  is  the  name  of  a  terminal  of  one  */ 

/*  of  Module's  component-parts.  Rule  2A  handles  primitive  */ 

/*  components  where  Rule  2B  handles  non-primitive  components.  */ 

/*  The  only  real  difference  is  where  to  locate  the  Components  */ 

/*  derived  behavior  (output.eqn  vs  derived.behavior) .  If  it  */ 

/*  is  later  decided  to  assert  a  derived.behavior  clause  for  */ 

/*  primitives,  then  Rule  2A  can  be  removed.  */ 

/*********>m***************************************************/ 

derive.behavior (Module,  Form,  Behavior)  :- 
Form  \==  i. 

Form*..  [F,G], 

part (Module,  G,  Component), 

not  part (Component, _,_) ,  /*  Component  is  a  primitive  module  */ 

output_eqn(Component ,  Form  :*  OutForm) , ! , 

writeln( [’Applying  Rule  2A  to  ’,  Form]), 

writeln( [Component,  ’  ”s  output  equation:  *3)  , 

writeln([’  ’,  Form,  ’  :*  *,  OutForm]), 

derive.behavior (Module,  OutForm,  Behavior).  /*  replace  gate  */ 

I*  inputs  with  module  variables  */ 
derive.behavior (Module,  Form,  Behavior)  :- 
Form  \*»  1, 

Form*..  [F,G], 

part (Module,  G,  Component),  /*  from  cut,  not  primitive  component  */ 

/*  previously  verified  due  to  verify.components  in  verify  clause  */ 

derived.behavior(Component, Form, OutForm) , ! , 

wr it eln( [’Applying  Rule  2B  to  ’,  Form]), 

writeln( [Component,  ” '8  derived  behavior:’]), 

writeln([’  ’,  Form,  ’  :*  ’,  OutForm]), 

derive.behavior (Module, OutForm, Behavior) .  /*  replace  gate  */ 

/*  inputs  with  module  variables  */ 
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/*************************************************************/ 

I*  The  remaining  rules  cover  cases  in  which  FORM  is  not  the  */ 

/*  name  of  a  terminal,  but  is  a  formula  involving  such  name.  */ 

/*  This  is  where  additional  types  of  boolean  or  non-boolean  */ 

/*  behavioral  rules  can  be  added  in  future  work.  These  rules*/ 

/*  simplify  internal  components  of  a  specified  behavioral  */ 

/*  structure.  The  evaluatel  clause  is  a  simple  canonicalizer*/ 

/*  which  should  also  be  modified  if  new  behaviors  are  added.  */ 

/%***************:M4^*****:M**********************************/ 

derive.behavior (Module,  neg(Form),  Behavior) 

! ,writeln( [’Applying  Rule  3  to  ’ ,neg(Form)]) , 
derive_behavior (Module,  Form,  Behi), 
evaluatel (neg(Behl) ,  Behavior), 
derive.behavior (Modulo,  and(Formi,Form2) ,  Beh) 

! ,writeln([’ Applying  Rule  4  to  ’ ,and(Forml,Form2)] ) , 
derive_behavior(Module,  Forml,  Behl), 
derive.behavior (Module,  Form2,  Beh2), 
evaluatel (and(Behl ,Beh2) ,  Beh) . 
derive.behavior (Module,  or (Forml, Form2) ,  Beh) 

! ,writeln([’ Applying  Rule  5  to  ’ ,or(Forml,Form2)] ) , 
derive.behavior (Module,  Forml,  Behl), 
derive.behavior (Module,  Form2,  Beh2), 
evaluatel (or (Behl, Beh2) ,  Beh). 
derive.behavior (Module,  if (Cond.Texp.Fexp) ,  Beh) 

! ,writeln([’ Applying  Rule  6  to  ’ ,if (Cond,Texp,Fexp)] ) , 
derive.behavior (Module,  Cond,  NCond), 
derive.behavior (Module,  Texp,  NTexp), 
derive.behavior (Module,  Fexp,  NFexp), 
evaluatel(if (NCond, NTexp, NFexp) ,  Beh) . 
derive.behavior (Module,  First  +  Second,  Beh) 

! ,writeln([ ’Applying  Rule  7  to  ’ .First  +  Second]), 
derive.behavior (Module,  First,  Behl), 
derive.behavior (Module,  Second,  Beh2), 
evaluatel (Behl  +  Beh2,  Beh). 

/t*****^*t**t***********************************************/ 

/*  The  default  rule  catches  behavior  which  we  haven’t  yet  */ 

/*  described  in  a  rule  or  which  shouldn’t  be  described.  */ 
/************************************************************/ 
derive.behavior (Module,  Form,  Form)  /*  default  Rule  */ 

writeln([’ Applying  default  Rule  to  ’.Form]). 
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/**********************************************************/ 


/*  */ 

/*  DERSTATE.PRO  */ 

/*  */ 

/*  The  clause  derive.states  finds  a  state  variable  */ 

/*  for  a  Module,  how  this  state  variable  fits  into  the  */ 

/*  internal  structure  of  the  Module,  derives  the  behavior*/ 

/*  of  the  internal  structure,  and  substitutes  the  */ 

/*  state  variable  name  for  the  internal  name  whenever  it  */ 

/*  appears  in  the  derived  behavior.  The  state.of,  */ 

/*  state.map,  and  state.eqn  facts  from  the  specified  */ 

/*  Module  description  are  used  to  identify  the  */ 

/*  appropriate  variables.  Then  the  two  clauses  */ 

/*  derive.behavior  and  substitute.state  are  invoked  to  */ 

/*  create  the  desired  Next.State.  */ 

/*  */ 

/ft******************************************************#**/ 

derive.states (Module, State, Next.State) 


state.of (Module, State, Type) ,  /*  It  has  state  */ 
state.map (Module, State, Internal) ,  /*  It’s  mapped  to  an  internal  part  */ 
state_eqn(Part, Internal  :«  NextState/*  internal  state  is  function  of  */ 
derive.behavior (Module, NextState.Beh),  /*  inputs  and  previous  state  */ 
substitute_8tate(Module,Beh, Next.State) . 

/ +♦♦♦♦♦♦*♦♦*♦**♦♦*♦♦**♦*♦♦♦*♦*♦*♦*♦♦♦♦*♦♦♦*****************/ 


/*  */ 

/*  sub8titute_state  */ 

/*  */ 

/*  This  clause  uses  replace.all  to  replace  occurrences  */ 

/*  of  internal  variables  with  the  appropriate  external  */ 

/*  black-box  variable  obtained  by  the  state.map  fact.  */ 


/**********************************************************/ 

substitute.state (Module , DerBeh , SubBeh)  : - 
st  at  e.map  (  Modul  e ,  Ext  emal  .Internal), 

! ,writeln( [’Derived  Behavior:  ’ .DerBeh]) , 
replace.all (Module, Internal, External, DerBeh, SubBeh) , 
writeln( [’Substituted  Behavior:  ’ .SubBeh] ) . 
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/***4^****>M***********************************************/ 

/*  */ 

/*  replace. all  */ 

/*  Replaces  each  occurrence  of  in  internal  variable  or  */ 

/*  other  variables  connected  to  this  internal  variable  */ 

/*  with  the  appropriate  external  balck-box  variable.  */ 

/*  The  replace  clauses  allow  you  to  traverse  any  type  */ 

/*  of  behavioral  structure  and  replace  the  appropriate  */ 

/*  variable  name.  New  replace  clauses  will  need  to  be  */ 

/*  added  when  new  behavioral  structures  are  created.  */ 
/****************>m*********#******************************/ 

replace.all (Module, Old, New ,01dBeh,SubBeh) 
replace(01d,Now,DldBeh,SB) , 

(  connected (Module, Old, Other)  ; 

output_eqn(Part, Other  :«  Old)  ),!, 
raplace.all (Module, Other, New, SB, NewSB) , 

evaluate!. (NewSB.SubBeh) .  /*  Simplify  further  if  possible  */ 

replace.all (Module, Old, New, Beh.Beh)  /*  no  more  connections  */ 

replace (Old, New, Other, Other) 
atomic (Other), 
write(’Rule2’) ,nl, ! . 
replace (Old, New, Other, Other) 
var (Other) , 
write ( ’ Rule3 ' ) ,nl , ! . 
replace (Old, New, Other, Other) 

Old  [F,Argl],  /*  keeps  in(X)  *  in(incA(X))  */ 

Other  *..  [G,Arg2],  /*  from  occuring,  occurs  test  */ 

F  \==  G, 

(  var(Arg2)  ;  atomic(Arg2)  ),  /*  already  simplified  */ 

write(’Rule4’) ,nl, ! . 

replace(01d,New,and(X,Y) ,and(NewBl,NewB2)) 

! ,write(’Rule  and’),nl, 
replace(01d,New,X,NewBl) , 
replace ( Old , New , Y , NewB2) . 
replace(01d,New,or(X,Y) ,or(NewBl,NewB2)) 

! ,write( ’Rule  or’),nl, 
replace(01d,New,X,NewBl) , 
replace(01d,New,Y,NewB2) . 
replace(01d,New,neg(X) ,neg(NewB)) 

! .write ('Rule  neg’),nl, 
replace(01d,New,X,NewB). 
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replace(01d,New,X  +  Y.NewBl  +  NewB2) 

! , write (’Rule  +  O.nl, 
replace(01d,New,X,NewBl) , 
replace(01d,New,Y,NewB2) . 

replace (Old , New , if (Cond ,Texp , Fexp) , if (NewB 1 , NewB2 , NewB3) )  : - 
! ,write(’Rule  ifO.nl, 
replace(01d, New, Cond, NewBl) , 
replace(01d,New,Texp,NewB2) , 
replace (Old, New, Fexp, NewB3) . 

replace(01d, New, Other, NewB)  /*  in(X)  /==  in(incA(X))  */ 

Old  * . .  [F ,Argl] , 

Other*..  [F,Arg2], 

(  (  var(Argl) ,  not  var(Arg2)  ); 

(  not  var(Argl),  var(Arg2)  )  ), 
replace (Old, New, Arg2,NewArgs) , 

NewB  *..  [F.NewArgs],  /*  Old  behavior  or  Old  Behavior  is*/ 

write(’Rule  8tructO.nl,!.  /*  some  other  nested  structure  */ 
replace (Old, New .Old, New) 

write(’Rule  10,  nl,!.  /*  If  you  find  X  replace  with  Y  */ 

replace (Old, New, Other, Other) 

write  (’Default  RuleO.nl.  /*  default  rule.  */ 
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/>M*********************************************************/ 


I*  */ 
/*  EQBEH.PRO  */ 
/*  This  file  contains  procedures  necessary  to  determine  */ 
/*  the  equivalence  of  a  derived  behavior(next  state)  and  */ 
/*  specified  behavior(next  state) .  */ 


/*  The  equal .behaviors  and  equal.states  clauses  are  used  */ 

/*  by  derive.and.equate.behaviors  and  derive. and.equate.  */ 

/*  states  to  provide  for  every  output/state  equivalence.  */ 

/*  The  primary  methods  of  equivalence  determination  used  */ 

/*  are  simiplification  and  boolean  expansion.  The  eqb  */ 

/*  clauses  will  require  expansion  in  further  work.  */ 

/*  */ 
/**t********************************************************/ 

equal.behaviors (Module , Output , Derived.Beh)  : - 

output _eqn (Module, Output  :«  Specif ied.Beh) ,/*  get  specified  behavior  */ 
eqb (Module , Derived.Beh , Specif ied.Beh) . 
equal.states (Module, Nextstate,Derived.State) 

8tate_eqn(Module,Next8tate  :*  Function),  /*  get  specified  state  */ 

eqb (Module , Der ived.St ate , Function) . 

/****>M************************4^***4^**********************/ 

/*  ■  TRIVIAL  IDENTITY  */ 

/*+++++++++*+++**+++++**++*+**+****+*********+****++*+**+***/ 

eqb(M,X,X) 
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/***********************************************************/ 

/*  BOOLEAN  EXPANSION  */ 

/*  The  clause  eq(NewDB,NewSB)  is  the  driver  for  the  code  */ 

/*  found  in  boole2.pro  which  performs  CPT  Dukes  boolean  */ 

/*  expansion.  */ 

/******4^*>M************************************************/ 

eqb(M,DB,SB) 

/*  expandable (M) ,  fewer  than  too  be  determined  combinations  */ 

/*  and  boolean  variables  */ 

evaluate_dukes(DB,NevDB) , 
evaluate_dukes(SB,NewSB) , 

writeln(['Does  ’,NewDB,’  «’]) ,writeln([’  ’.NewSB]), 

eqCNewDB, NewSB) , 

writeln([DB, *  *’]) ,writeln([’  '.SB]), 
writeln([’By  Boolean  Expansion’]),!. 

expandable(M)  /*  some  how_many  function  will  */ 

port(H,_,_,boole) , ! .  /*  be  required  */ 

/***********************************************************/ 

/*  SIMPLIFICATION  */ 

/***********************************************************/ 

eqb(M,DB,SB) 

evaluatel(DB,NDB) , 
evaluatel(SB.NSB) , 

(  DB  \=*  NDB  ; 

SB  \==  NSB  ) , 

writeln([’ Derived  behavior  is:  ’,DB]), 
eqb(M,NDB,NSB),  !. 
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/************************************************************/ 


/*  */ 

/*  VERIFY. PRO  */ 

/*  This  clause  provides  the  user  interface  for  the  entire  */ 
/*  VERIFY  Prototype.  When  a  user  types  verify (Module) ,  */ 

/*  after  loading  the  appropriate  files,  the  verify  clause  */ 
/*  invokes  other  clauses  to  recursively  verify  each  */ 

/*  Module.  Each  verify  clause  handles  a  different  type  */ 
/*  of  Module  as  noted  beside  each  head.  The  part  and  */ 

/*  state.eqn  clauses  provided  in  Module  descriptions  are  */ 
/*  used  to  determine  Module  type.  Other  clauses  used  are  */ 
/*  the  following:  */ 

/*  */ 

/*  derive_and_equate_behaviors :  provides  mechanism  to  */ 

/*  derive  behavior  for  each  output,  and  determine  */ 

/*  equivalence  to  specified  behavior.  */ 

/*  derive_and_equate_states :  provides  mechanism  to  */ 
/*  derive  behavior  for  each  next  state,  and  */ 

/*  determine  equivalence  to  specified  next  state.  */ 

/*  verif y.components :  uses  verify  to  recursively  */ 

/*  verify  components  prior  *o  deriving  component  */ 

/*  behavior  and  next  state.  */ 


/t********:^******^*****************************************/ 

verify (Module)  /*  previously  verified  module  */ 

verif ied (Module) , ! , 

writeln([,»>’ .Module, '  previously  verified  »>*]). 
verify (Module)  /*  primitive  module  with  no  state  */ 

not  part (Module, _,_) , 
not  state_eqn(Module,_) , ! , 

/t*******^****!)^********]^*^*******************************/ 

/*  For  a  primitive  module,  behavior  *  structure.  */ 

/*  No  need  to  reassert  this  in  the  database,  since  it  can  */ 

/*  be  taken  from  the  behavioral  specification.  */ 

/*  output_eqn(Module ,  Output  :■  Behavior).  ALREADY  EXISTS  */ 

/*  If  it  is  decided  that  derived.behavior  should  appear  as**/ 

/*  as8erta(derived_behavior(Module, Output, Behavior) ),  the  */ 

/*  derive.behavior  clause  dealing  with  primitives  can  be  */ 

/*  removed.  A  similar  decision  is  required  for  the  */ 

/*  a8serta(verif ied(Module))  for  a  primitive  Module.  With**/ 

/*  only  one  possible  verified  clause  per  Module,  I  felt  */ 

/*  the  space  required  was  minimal  for  the  time  savings.  */ 

/***********************************>************************/ 
asserta(verif ied(Module) ) , 

writeln([,»>’  .Module,  *  primitive  (needs  no  verification) »>’])  . 
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verify (Module)  l*  primitive  module  with  state  */ 

not  part (Module, _,_),! , 

/*  Also,  no  need  to  reasert  next  state  either.  */ 

/*  state_eqn(Module,Nextstate  :*  Function)  ALREADY  EXISTS  */ 

asserta(verif ied (Module) ) , 

writeln^’^’  .Module,*  primitive  (needs  no  verification)  >»’]) . 
verify (Module)  /*  non-primitive  with  no  state  */ 

not  state_eqn(Module,_) , 

writeln([’»>  Attempting  to  verify  *  .Module,  ’»>’])  , 
verif y.components (Module) , ! , 

/*******+****************************************************/ 

/*  Derive  behavior  for  all  outputs  and  if  equal  to  */ 

/*  specified  behavior,  then  assert  in  database.  This  may  */ 

/*  require  later  garbage  collection  if  the  earlier  outputs  */ 

/*  are  okay,  but  a  later  output  is  not.  This  would  require  */ 

/*  a  cleanup  to  check  the  verif ied(Module)  against  the  */ 

/*  derived.behavior  and  next.state  clauses.  If  the  clauses  */ 

/*  are  not  consistent,  then  remove  all  derive.behavior  and  */ 

/*  next.state  clauses.  */ 

/ ************************************************************/ 
derive.and.equate.behaviors (Module) , 
asserta(verif ied(Module) ) , 

writeln([’<«Succe8s!  Behavior  of ’ .Module, ’meets  its  specification.’]), 
verify (Module)  /*  non-primitive  with  state  */ 

writeln([*»>  Attempting  to  verify  ’  .Module, ’>»’])  , 
verif y.components (Module) , 

i 

•  9 

derive.and.equate.behaviors (Module) , 
derive.and.equate.states (Module) , 
a8serta(verif ied(Module)) , 

writeln([*<<<Succe88!  Behavior  of ’ .Module, 'meets  its  specification.’]). 
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z****^^*********************^*****************************/ 

/*  The  first  clause  of  the  next  three  procedures  always  */ 
/*  succeeds.  We  need  a  way  to  check  that  all  components  */ 
/*  are  verified,  and  all  behaviors  and  next.states  are  */ 
/*  equivalent.  The  second  clause  of  each  procedure  does  */ 
/*  this  checking  by  generating  lists  of  components,  states,*/ 
/*  and  outputs  and  comparing  the  length  of  the  two  lists  */ 
/*  for  the  states  and  outputs  since  no  two  state  or  output  */ 
/*  names  should  be  generated  twice  for  a  single  module.  */ 
/*  Setof  will  generate  all  Components  for  a  single  module,  */ 
/*  so  we  just  check  to  see  if  that  component  was  actually  */ 
/*  verified.  */ 

/****************************>^*#****************************/ 

derive. and. equate .behaviors (Module)  : - 

der i ve.behaviors (Module , Output , Der ived.Beh) , 
equal.behaviors (Module, Output ,Derived„Beh) , 
asserta(derived_behavior (Module, Output, Derived.Beh)) , 
fail. 

derive.and.equate.behaviors (Module)  :  - 

setof (Outputs, output.eqn (Module, Outputs  :=  _),0utlist), 
length(Outlist,Outnum) , 

setof (Outputs, derived.behavior (Module, Outputs,.) ,Derlist) , 
length(Derli8t,Dernum) , 

Outnum  «:*  Dernum. 

derive.and.equate.behaviors (Module)  :  - 

retract (derived.behavior (Module ,_,„)), 
fail. 

derive.and.equate.states (Module)  :  - 

derive.states (Module .State , Next .State) , 
equal.states (Module , State , Next. State) , 
asserta(next_8tate(Module, State, Next.State)) , 
fail. 

derive.and.equate.states (Module)  : - 

setof (States, state.eqn(Module, States  :*  _) .Statelist) , 
length(Statelist .Statenum) , 

setof (States, next.8tate(Module, States,.) .Derlist) , 
length(Derlist , Dernum) , 

Statenum  =:=  Dernum. 
derive.and.equate.states (Module)  : - 
retract (next. state (Module ,_,_)), 
fail. 
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verify  .component  8  (Module)  im¬ 
part  (Module,.,  Component)  , 
verify (Component) , 
fail. 

verify.components (Module) 

setof (Component, part (Module, ..Component) .Complist) , 

parts.verif ied(Complist) , 

writeln([* component  list  is  ',  Complist]). 

/************************************************************/ 
/*  */ 

/*  parts.verfied  -  This  procedure  ensures  that  all  parts  */ 

/*  (Components)  of  a  Module  have  been  verified.  A  list  */ 

/*  of  parts (Components)  generated  by  setof  is  passed,  */ 

/*  and  parts.verif ied  checks  that  each  one  has  an  asserted*/ 

/*  verified  fact.  */ 

/*  */ 

/> ************************************************************/ 

parts.verif ied(  □ ) . 
parts.verif ied( [Component  I Tail] )  :  - 
verif ied(Component) , 
parts.verif ied(Tail) . 
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/******************************************************/ 
/*  */ 

/*  Counter. pro  */ 

/*  */ 

/*  Module  definitions  for  the  counter  example  */ 

/*  in  Barrow’s  VERIFY  article.  */ 

/*  */ 

/*>m***************************************************/ 


/*- 


module.name(inc) . 


INCREMENTER 


■*/ 


port(inc,in(AnInc) , input , integer) . 
port ( inc , out (Anlnc) , output , integer) . 

/*  Behavior  Specification  */ 

output_eqn(inc,  out(Anlnc)  :=  1  +  in(Anlnc)). 

/* -  MULTIPLEXER  - 

module_name(mux) . 


■*/ 


port (mux , inO ( AMux) , input , integer) . 
port (mux , ini (AMux) , input , integer) . 
port  (mux, switch (AMux) .input ,boole) . 
port (mux , out (AMux) , output , integer) . 

/*  Behavior  Specification  */ 

output_eqn(mux,  out(AMux)  :*  if (switch(AMux) , 

ini (AMux) , 
inO(AMux))). 
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REGISTER 


/* 


*/ 


module_name(reg) . 

port (reg, in(AReg) .input, integer) . 
port (reg , out ( AReg) , output , integer) . 

/*  Behavior  Specification  */ 

state.of (reg, contents (AReg) .integer) . 

output.eqn (reg, out (AReg)  :*  contents (AReg) ) . 

state_eqn(reg, contents (AReg)  :*  in(AReg)). 

/* .  COUNTER . */ 

module_name(counter) . 

port (counter , in(ACounter) , input , integer) . 
port (counter, Ctrl (ACounter) , input, boole) . 
port (counter , out (ACounter) , output , integer) . 

part (counter ,muxA (ACounter) ,mux) . 
part(counter,regA(ACounter) ,reg) . 
part(counter,incA(ACounter) ,inc) . 

connected (counter, Ctrl (ACounter) , switch (muxA (ACounter))) . 
connected(counter , in(ACounter) , ini (muxA (ACounter) ) ) . 
connected(counter, out (muxA (ACounter)) ,in(regA (ACounter))) . 
connected(counter,out(regA(ACounter)) ,in(incA (ACounter))) . 
connected(counter,out(incA(ACounter)) ,inO(muxA(ACtunter))) . 
connected(counter,out(regA(ACounter)) , out (ACounter) ) . 

/*  Behavior  Specification  */ 

state.of (counter, count (ACounter) .integer) . 
state_map(counter,count(ACounter) , contents (regA(ACounter))) . 

output_eqn(counter,out(ACounter)  :*  count (ACounter)  ). 

state_eqn(counter,  count (ACounter)  :*  if (ctrl (ACounter) , 

in (ACounter) , 

count (ACounter)  +  1)). 
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/***>M*********************4^*******************************/ 


t*  XOR.PEO  */ 
/*  This  file  provides  the  module  descriptions  for  2-input  */ 
/*  nands  and  exclusive  ors.  This  file  is  required  when  */ 
/*  verifying  a  fulladder.  */ 
/*  */ 


/***********************************************************/ 

/* -  Structural  Specification  for  2-input  NAND  - */ 

module_name(nand2) . 

port (nand2 , inO (ANand2) , input ,boole) . 
port (nand2, ini (ANand2) .input ,boole) . 
port (nand2 , out (ANand2) , output ,boole) . 

/*  Behavioral  Specification  */ 

output. eqn (nand2 , 

out(ANand2)  :*  or(  neg(inO(ANand2)) ,  neg(inl(ANand2)))  ). 

/*  Structural  specification  for  a  two-input  Exclusive -OR  */ 

module_name(xor) . 

port (xor.inO(AnXor) .input ,boole) . 
port (xor, ini (AnXor) , input ,boole) . 
port (xor, out (AnXor) , output fboole) . 

part (xor, gl (AnXor) ,nand2) . 
part (xor, g2(AnXor) ,nand2) . 
psurt (xor, g3 (AnXor)  ,nand2) . 
part (xor, g4 (AnXor) ,nand2) . 

connected(xor,inO(AnXor) ,inO(gl (AnXor) )) . 
connected(xor , ini (AnXor) , ini (gl (AnXor) ) ) . 
connected(xor,inO (AnXor) ,inO(g2(AnXor))) . 
connected(xor,out(gl(AnXor)) , ini (g2 (AnXor))) . 
connected(xor,out(gl(AnXor)) , in0(g3( AnXor))) . 
connected(xor, ini (AnXor) ,inl(g3(AnXor))) . 
connected (xor, out (g2( AnXor)) , in0(g4 (AnXor) )) . 
connected(xor, out (g3 (AnXor)) , ini (g4( AnXor))) . 
connected(xor,out(g4( AnXor) ) , out (AnXor) ) . 


A-31 


/*  Behavioral  Specification  for  a  two-input  XOR  */ 
output_eqn(xor, 

out(AnXor)  :■  or(  and(  neg(inOCAnXor)) , 

inl(AnXor)  ), 
and(  inO(AnXor), 

neg(inl(AnXor))  ))). 


A-32 


/*********4^4^**********************************************/ 


/*  FADDXOR.PRO  */ 
/*  This  file  provides  the  specification  of  a  fulladder  */ 
/*  composed  of  nand  and  exclusive  or  gates.  The  file  */ 
/*  xor.pro  must  also  be  loaded  to  provide  the  module  */ 
/*  specifications  for  nand2  and  xor.  */ 
/*  */ 


/***********************************************************/ 

/*  Structural  specification  for  a  full  adder  with  xors  */ 

module.nameCf addxor) . 

port(faddxor,x(Afaddxor) , input, boole) . 
port (f addxor, y(Af addxor) .input, boole) . 
port (f addxor, cin(Af addxor) .input, boole) . 
port Cf addxor, outcarry CAf addxor) .output, boole) . 
port (f addxor, outsum(Af addxor) .output, boole) . 

part (f addxor, gl(Af addxor) ,nand2) . 
part (f addxor, g2(Af addxor) ,nand2) . 
part (f addxor, g3(Af addxor) ,nand2) . 
part(faddxor,g4(Afaddxor) ,xor) . 
part(faddxor,g5(Afaddxor) ,xor) . 

connected (f addxor, x(Af addxor) ,inO(gi(Af addxor))) . 
connected (f addxor, y(Af addxor) ,inl(gl (Af addxor)) ) . 
connectedCf addxor, cin(Af addxor) ,inO(g2(Af addxor))) . 
connectedCf addxor, out (g4(Af addxor)) , ini (g2(Af addxor))) . 
connectedCf addxor, out (gl(Af addxor) ) ,in0(g3 (Af addxor))) . 
connectedCf addxor, out (g2(Af addxor)) ,inl(g3(Af addxor))) . 
connected(faddxor, x(Af addxor) ,inO(g4(Af addxor))) . 
connectedCf addxor, y(Af addxor) ,inl(g4(Af addxor))) . 
connectedCf addxor , out  Cg4CAf addxor) ) , inO  Cg5  CAf addxor) ) ) . 
connectedCf addxor, cinCAf addxor) , ini Cg5 CAf addxor))) . 
connectedCf addxor, out CgSCAf addxor)) .outsumCAf addxor)) . 
connectedCf addxor, out Cg3CAf addxor)) .outcarry CAf addxor)) . 
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/*  Behavioral  Specification 


*/ 


output  _  eqn (f  addxor , 

outcarry (Af addxor)  :  ■ 
or(  and(  x(Afaddxor) ,y(Afaddxor)) , 
and(  cin(Af addxor) , 

xor(  x(Af addxor) ,y(Af addxor))  ))). 

output  _  eqn (f  addxor , 

outsua(Af addxor)  :■ 
xor(  xor(x(Af addxor) ,y(Af addxor)) , 
cin(Af addxor)  )). 
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Appendix  B.  Sample  Sessions 


This  Appendix  includes  sample  runs  of  a  counter-circuit  and  fulladder  on  Prolog- 1 
and  Quintus  Prolog. 


/**************)M****]|^*********Mi**************************/ 

/*  This  file  loads  the  appropriate  files  to  verify  a  */ 

/*  a  counter  with  Quintus  Prolog.  This  is  invoked  by  */ 

/*  typing  [’qctrld.pro’].  */ 

/************£**********************************************/ 

?-  [’qops.pro* , ’eval.pro’ , ’derbeh.pro* , *der state. pro* , ’counter. pro’] . 

?-  [’boole2.pro* , ’eqbeh.pro* , ’verify. pro’] . 

Sample  Run  for  a  counter-circuit  on  Quintus  Prolog: 

[l]cub  prolog 

Quintus  Prolog  Release  2.4  (VAX,  Ultrix  2. 0-2. 2) 

Copyright  (C)  1988,  Quintus  Computer  Systems,  Inc.  All  rights  reserved. 

1310  Villa  Street,  Mountain  View,  California  (415)  965-7700 

I  ?-  [’qctrld.pro’] . 

[consulting  /usr/users/gce90d/ksparks/15j an91 /qctrld.pro. . .] 

[consulting  /usr/users/gce90d/k8parks/15jan91/qops.pro. . .] 

[Undefined  procedures  will  just  fail  (’fail’  option)] 

[qops.pro  consulted  0.367  sec  1,092  bytes] 

[consulting  /usr/u8ers/gce90d/k8parks/15jan91/eval.pro. . .] 

[WARNING:  Singleton  variables,  clause  3  of  evaluate_brown/2:  F] 

[eval.pro  consulted  1.050  sec  2,920  bytes] 

[consulting  /usr/users/gce90d/ksparks/15jan91/derbeh.pro. . .] 

[WARNING:  Singleton  variables,  clause  1  of  derive_behaviors/3 :  Spec.Behavior] 
[WARNING:  Singleton  variables,  clause  2  of  derive.behaviors/3 :  Spec.Behavior] 
[WARNING:  Clauses  for  derive_behavior/3  are  not  together  in  the  source  file] 
[WARNING:  Singleton  variables,  clause  1  of  derive_behavior/3 :  F] 

[WARNING:  Singleton  variables,  clause  2  of  derive_behavior/3:  F] 

[WARNING:  Singleton  variables,  clause  8  of  derive.behavior/3 :  Module] 
[derbeh.pro  consulted  1.466  sec  3,220  bytes] 

[consulting  /usr/users/gce90d/ksparks/15jan91/derstate.pro. . .] 

[WARNING:  Singleton  variables,  clause  1  of  derive.states/3:  Type,  Part] 

[WARNING:  Singleton  variables,  clause  1  of  replace. all/5:  Part] 

[WARNING:  Singleton  variables,  clause  2  of  replace. all/5:  Module,  Old,  New] 

[WARNING:  Singleton  variables,  clause  1  of  replace/4:  Old,  New] 


B-l 


[WARNING:  Singleton  variables,  clause  2  of  replace/4:  Old,  New] 

[WARNING:  Singleton  variables,  clause  3  of  replace/4:  New,  Argl] 

[WARNING:  Singleton  variables,  clause  11  of  replace/4:  Old,  New] 
[derstate.pro  consulted  1.384  sec  2,872  bytes] 

[consulting  /usr/ussrs/gce90d/ksparks/i5jan9i/counter.pro. . .] 

[WARNING:  Singleton  variables,  clause  1  of  port/4:  Anlnc] 

[WARNING:  Singleton  variables,  clause  2  of  port/4:  Anlnc] 

[WARNING:  Clauses  for  module_name/l  are  not  together  in  the  source  file] 
[WARNING:  Clauses  for  port/4  are  not  together  in  the  source  file] 
[WARNING:  Singleton  variables,  clause  1  of  port/4:  AMux] 

[WARNING:  Singleton  variables,  clause  2  of  port/4:  AMux] 

[WARNING:  Singleton  variables,  clause  3  of  port/4:  AMux] 

[WARNING:  Singleton  variables,  clause  4  of  port/4:  AMux] 

[WARNING:  Clauses  for  output_eqn/2  are  not  together  in  the  source  file] 
[WARNING:  Singleton  variables,  clause  1  of  port/4:  AReg] 

[WARNING:  Singleton  variables,  clause  2  of  port/4:  AReg] 

[WARNING:  Singleton  variables,  clause  1  of  state_of/3:  AReg] 

[WARNING:  Singleton  variables,  clause  i  of  port/4:  ACounter] 

[WARNING:  Singleton  variables,  clause  2  of  port/4:  ACounter] 

[WARNING:  Singleton  variables,  clause  3  of  port/4:  ACounter] 

[WARNING:  Singleton  variables,  clause  1  of  part/3:  ACounter] 

[WARNING:  Singleton  variables,  clause  2  of  part/3:  ACounter] 

[WARNING:  Singleton  variables,  clause  3  of  part/3:  ACounter] 

[WARNING:  Clauses  for  state_of/3  are  not  together  in  the  source  file] 
[WARNING:  Singleton  variables,  clause  1  of  state_of/3:  ACounter] 

[WARNING:  Clauses  for  state_eqn/2  are  not  together  in  the  source  file] 
[counter. pro  consulted  1.766  sec  3,804  bytes] 

[consulting  /usr/users/gce90d/ksparks/15jan91/boole2.pro. . .] 

[WARNING:  Singleton  variables,  clause  1  of  remove_x_l/3:  X] 

[WARNING:  Singleton  variables,  clause  2  of  remove_x_i/3:  X] 

[WARNING:  Singleton  variables,  clause  3  of  remove_x_l/3:  Arg2] 

[WARNING:  Singleton  variables,  clause  4  of  remove_x_l/3:  Arg,  Argl,  Arg2] 
[WARNING:  Singleton  variables,  clause  5  of  remove_x_l/3:  Arg2] 

[WARNING:  Singleton  variables,  clause  6  of  remove_x_l/3:  Arg2] 

[WARNING:  Singleton  variables,  clause  1  of  remove_x_0/3 :  X] 

[WARNING:  Singleton  variables,  clause  2  of  remove_x_0/3 :  X] 

[WARNING:  Singleton  variables,  clause  3  of  remove_x_0/3:  Arg2] 

[WARNING:  Singleton  variables,  clause  4  of  remove_x_0/3:  Arg2] 

[WARNING:  Singleton  variables,  clause  5  of  remove_x_0/3:  Arg2] 

[WARNING:  Singleton  variables,  clause  6  of  remove_x_0/3:  Arg2] 

[boole2.pro  consulted  2.600  sec  6,820  bytes] 

[consulting  /usr/users/gce90d/ksparks/15jan9i/eqbeh.pro. . .] 

[WARNING:  Singleton  variables,  clause  1  of  eqb/3:  M] 

[WARNING:  Singleton  variables,  clause  2  of  eqb/3:  M] 

[WARNING:  Clauses  for  eqb/3  are  not  togethor  in  the  source  file] 
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[eqbah.pro  consulted  0.600  sec  1,244  bytes] 

[consulting  /usr/users/gce90d/ksparks/15jan91/verify.pro. . .] 

[verify. pro  consulted  1.134  sec  3,036  bytes] 

[qctrld.pro  consulted  11.166  sec  25,776  bytes] 
yes 

I  ?-  verify (counter) . 

»>  Attempting  to  verify  counter»> 

»>mux  primitive  (needs  no  verification)  >» 

»>reg  primitive  (needs  no  verification) >>> 

»>inc  primitive  (needs  no  verification)  »> 

Applying  Rule  IB  to  out(_681) 

Applying  Rule  2A  to  out(regA(_681)) 
reg’s  output  equation: 

out(regA(_681))  :*  contents(regA(_681)) 

Applying  default  Rule  to  contents(regA(_681)) 

Derived  Behavior:  contents (regA(_681)) 

Rule  1 
Rule4 
Rule4 
Rule4 

Value  of  count (_681): 

count(_68i) 

Value  of  count („681): 

count (_681) 

Value  of  count(_681): 

count (_681) 

Substituted  Behavior:  count(_68i) 

Applying  Rule  IB  to  in(regA(_1274)) 

Applying  Rule  2A  to  out (muxA(_ 1274)) 
mux’s  output  equation: 

out (muxA(_ 1274))  :«  if (switch (muxA (.1274)) , ini (muxA(_ 1274)) ,inO(muxA(_1274))) 
Applying  Rule  6  to  if (switch (muxA(_ 1274)) ,inl(muxA(_1274)) ,inO(muxA(_1274))) 
Applying  Rule  1A  to  svitch(muxA(_1274)) 

Applying  Rule  1A  to  ini (muxA(_ 1274)) 

Applying  Rule  IB  to  inO(muxA(_1274)) 

Applying  Rule  2A  to  out (incA(_ 1274)) 
inc’s  output  equation: 

out (incA(_ 1274))  :«  l+in(incA(_1274)) 

Applying  Rule  7  to  l+in(incA(_1274)) 

Applying  default  Rule  to  1 
Applying  Rule  IB  to  in(incA(_1274)) 

Applying  Rule  2A  to  out(regA(_1274)) 
reg’s  output  equation: 

out(regA(_1274))  :»  contents (regA(_ 1274)) 

Applying  default  Rule  to  contents (regA(_ 1274)) 
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Value  of  l+contents(regA(_1274)) : 

l+contents(regA(_1274) ) 

Value  of  if (ctrl (.1274) , in (. 1274) ,i+contents(regA(_ 1274))) : 

if (ctrl(_1274) ,in(_1274) ,l+contents(regA(.1274))) 

Derived  Behavior:  if (ctrl(_1274) ,in(_1274) ,l+contents(regA(_1274))) 

Rule  if 

Rule4 

Rule4 

Rule  + 

Rule2 
Rule  1 
Rule  if 
Rule4 
Rule4 
Rule  + 

Rule2 
Rule4 
Rule  if 
Rule4 
Rule3 

Rule  struct 
Rule  + 

Rule2 
Rule4 
Rule  if 
Rule4 
Rule4 
Rule  + 

Rule2 

Rule4 

Value  of  if (ctrl(. 1274) ,in(_1274) ,l+count(. 1274)) : 

if (ctrl(.1274) ,in(.1274) ,l+count(_1274)) 

Value  of  if (ctrl(_1274) ,in(.1274) , l+count(_1274)) : 

if (ctrl(_1274) ,in(_1274) ,l+count(.1274)) 

Value  of  if (ctrl(.1274) ,in(_1274) ,l+count(_1274)) : 

if (Ctrl (.1274) ,in(. 1274) ,l+count(. 1274)) 

Substituted  Behavior:  if (ctrl(_1274) ,in(_1274) ,l+count(_1274)) 

Does  if (ctrl (.1274) ,in(. 1274) ,count(_1274)+l)  = 
if (Ctrl (.1274) , in(.1274) , l+count(_1274) ) 

Value  of  if (ctrl(_1274) ,in(_1274) , count (.1274)+1) : 

if (ctrl(. 1274) ,in(_1274) ,l+count(. 1274)) 

Derived  behavior  is:  if (ctrl(_1274) ,in(_1274) ,count(_1274)+l) 

«<  Success!  Behavior  of  counter  meets  its  specification, 
yes 

I  ?-  halt. 
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/***********************************************************/ 
/*  This  fils  loads  the  appropriate  files  to  verify  a  */ 

/*  a  counter  on  PROLOG-1.  This  is  invoked  by  typing  */ 

/*  [‘a:ctrload’] .  */ 

/**>M*******************************************************/ 

?-  [’slops’ , ’a:eval’ , ’a:derbeh’ , ’a:derstate’ , ’a:counter’] . 

?-  [’a:boole2’ , ’areqbeh’ , ’arverify’] . 

Sample  run  for  a  counter-circuit  on  PROLOG-1: 

B:\>prolog 


+ 


+ 


I  MS-DOS  Prolog- 1  Version  2.2  I 

I  Copyright  1983  Serial  number:  0001213  I 
I  Expert  Systems  Ltd.  I 

I  Oxford  U.K.  I 


+ 


■+ 


?-  [’a:ctrload’] . 
a: ops  consulted. 
a:eval  consulted. 
a:derbeh  consulted. 
a:derstate  consulted, 
a: counter  consulted. 
a:boole2  consulted. 
a:eqbeh  consulted, 
a: verify  consulted. 
a:ctrload  consulted. 

?-  verify(counter) . 

»>  Attempting  to  verify  counter»> 

»>mux  primitive  (needs  no  verification) »> 
»>reg  primitive  (needs  no  verif  ication)»> 
»>inc  primitive  (needs  no  verif  ication)»> 
Applying  Rule  IB  to  out(_99) 

Applying  Rule  2A  to  out(regA(_99)) 
reg’s  output  equation: 

out(regA(_99))  :*  contents (regA(_99)) 
Applying  default  Rule  to  contents(regA(_99)) 
Derived  Behavior:  contents (regA(_99)) 

Rule  1 
Rule4 
Rule4 
Rule4 
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Value  of  count (_99): 

count (.99) 

Value  of  count (_99): 

count  (.99) 

Value  of  count (_99): 

count (.99) 

Substituted  Behavior:  count (.99) 

Applying  Rule  IB  to  in(regA(_171)) 

Applying  Rule  2A  to  out (muxA(_171)) 
mux’s  output  equation: 

out(muxA(_171))  :*  if (switch(muxA(_171)) ,inl(muxA(_171)) ,inO(muxA(_171))) 
Applying  Rule  6  to  if (switch(muxA(_171)) ,inl(muxA(_171)) ,inO(muxA(_171))) 
Applying  Rule  1A  to  switch(muxA(_171)) 

Applying  Rule  1A  to  inl(muxA(_171)) 

Applying  Rule  IB  to  inO(muxA(_17l)) 

Applying  Rule  2A  to  out(incA(_171)) 
inc's  output  equation: 

out(incA(_171))  :*  l+in(incA(_171)) 

Applying  Rule  7  to  l+in(incA(_171)) 

Applying  default  Rule  to  1 
Applying  Rule  IB  to  in(incA(_171)) 

Applying  Rule  2A  to  out(regA(_171)) 
reg’s  output  equation: 

out(regA(_171))  :•  contents(regA(.17i)> 

Applying  default  Rule  to  contents (regAC. 171)) 

Value  of  l+contents(regA(_171)) : 

l+content8(regA(_171)) 

Value  of  if (ctrl(_171) ,in(_171) ,l+contents(regA(_171))) : 

if (ctrl(_171) ,in(„171) , l+contents(regA(_171))) 

Derived  Behavior:  if (ctrl(_171) ,in(_171) ,l+contents(regA(_171))) 

Rule  if 
Rule4 
Rule4 
Rule  + 

Rule2 
Rule  1 
Rule  if 
Rule4 
Rule4 
Rule  + 

Rule'2 
Rule4 
Rule  if 
Rule4 
Rule3 
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Rule  struct 
Rule  + 

Rule2 
Rule4 
Rule  if 
Rule4 
Rule4 
Rule  + 

Rule2 

Rule4 

Value  of  if  (ctrl(_171)  ,in(_171)  ,l+count(..i71))  : 

if (ctrl(.171) ,in(_l71) ,l+count(.17i)> 

Value  of  if(ctrl(_171),in(_171),l+count(_171)): 

if (ctrl(_171) ,in(_171) ,l+count(.171)> 

Value  of  if (ctrl(_171) ,in(_171) ,l+count(.171)) : 

if (ctrl (> 171) ,in(_l71) ,l+count(_171)) 

Substituted  Behavior:  if (ctrl(_171) ,in(_171) ,l+count(_171)) 
Does  if (ctrl(_171) ,in(_171) ,count(_171)+l)  * 
if (ctrl (_ 171) ,in(_171) ,l+count(_17i)) 

Value  of  if (ctrl(_171) ,in(_171) , count (_171)+1) : 

if (ctrl(_171) ,in(_171) ,l+count(_171)) 

Derived  behavior  is:  if (ctrl(_171) ,in(_171) ,count(_171)+l) 
«<  Success!  Behavior  of  counter  meets  its  specification. 

yes 

?-  halt. 
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/******>M4^**>M*********************************************/ 

I*  This  file  loads  the  appropriate  files  to  verify  a  */ 

/*  a  fulladder  with  Quintus  Prolog.  This  is  invoiced  by  */ 

/*  typing  [’qfaddld.pro’] .  */ 

/********4^*************************************************/ 

?-  [’qops.pro* , 'eval.pro* , 'derbeh.pro'] . 

?-  ['derstate.pro' , 'xor.pro' , 'faddxor.pro'] . 

?-  [’boole2.pro* , 'eqbeh.pro' , ’verify. pro*] . 

Sample  run  for  a  full-adder  circuit  on  Quintus  Prolog: 

[l]cub  prolog 

Quintus  Prolog  Release  2.4  (VAX,  Ultrix  2. 0-2. 2) 

Copyright  (C)  1988,  Quintus  Computer  Systems,  Inc.  All  rights  reserved. 

1310  Villa  Street,  Mountain  View,  California  (415)  965-7700 

I  ?-  [’qfaddld.pro']. 

[consulting  /usr/users/gce90d/ksparks/15jan91/qfaddld.pro. . .] 

[consulting  /usr/users/gce90d/ksparks/15jan91/qops.pro. . .] 

[Undefined  procedures  will  just  fail  (’fail*  option)] 

[qops.pro  consulted  0.383  sec  1,092  bytes] 

[consulting  /usr/users/gce90d/ksparks/15jan91/eval.pro. . .] 

[WARNING:  Singleton  variables,  clause  3  of  evaluate_brown/2:  F] 

[eval.pro  consulted  1.050  sec  2,936  bytes] 

[consulting  /usr/users/gce90d/kspark8/15jan91/derbeh.pro. . .] 

[WARNING:  Singleton  variables,  clause  1  of  derive_behaviors/3:  Spec.Behavior] 
[WARNING:  Singleton  variables,  clause  2  of  derive_behaviors/3 :  Spec.Behavior] 
[WARNING:  Clauses  for  derive_behavior/3  sure  not  together  in  the  source  file] 
[WARNING:  Singleton  variables,  clause  1  of  derive_behavior/3 :  F] 

[WARNING:  Singleton  variables,  clause  2  of  derive_behavior/3 :  F] 

[WARNING:  Singleton  variables,  clause  8  of  derive_behavior/3:  Module] 
[derbeh.pro  consulted  1.450  sec  3,220  bytes] 

[consulting  /usr/users/gce90d/ksparks/15jan91/derstate.pro. . .] 

[WARNING:  Singleton  variables,  clause  1  of  derive_states/3:  Type,  Part] 

[WARNING:  Singleton  variables,  clause  1  of  replace.all/5:  Part] 

[WARNING:  Singleton  variables,  clause  2  of  replace_all/5:  Module,  Old,  New] 

[WARNING:  Singleton  variables,  clause  1  of  replace/4:  Old,  New] 

[WARNING:  Singleton  variables,  clause  2  of  replace/4:  Old,  New] 

[WARNING:  Singleton  variables,  clause  3  of  replace/4:  New,  Argl] 

[WARNING:  Singleton  variables,  clause  11  of  replace/4:  Old,  New] 

[derstate.pro  consulted  1.383  sec  2,904  bytes] 

[consulting  /usr/users/gce90d/ksparks/15jan91/xor.pro. . .] 

[WARNING:  Singleton  variables,  clause  1  of  port/4:  ANand2] 
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[WARNING:  Singleton  variables ,  clause  2  of  port/4:  ANand2] 

[WARNING:  Singleton  variables,  clause  3  of  port/4:  ANanJ2] 

[WARNING:  Clauses  for  module.nane/l  are  not  together  in  the  source  file] 
[WARNING:  Clauses  for  port/4  are  not  together  in  the  source  file] 
[WARNING:  Singleton  variables,  clause  1  of  port/4:  AnXor] 

[WARNING:  Singleton  variables,  clause  2  of  port/4:  AnXor] 

[WARNING:  Singleton  variables,  clause  3  of  port/4:  AnXor] 

[WARNING:  Singleton  variables,  clause  1  of  part/3:  AnXor] 

[WARNING:  Singleton  variables,  clause  2  of  part/3:  AnXor] 

[WARNING:  Singleton  variables,  clause  3  of  part/3:  AnXor] 

[WARNING:  Singleton  variables ,  clause  4  of  part/3:  AnXor] 

[WARNING:  Clauses  for  output_eqn/2  are  not  together  in  the  source  file] 
[xor.pro  consulted  1.184  sec  2,616  bytes] 

[consulting  /usr/users/gce90d/ksparks/15jan9i/faddxor.pro. . .] 

[WARNING:  Singleton  variables,  clause  1  of  port/4:  Afaddxor] 

[WARNING:  Singleton  variables,  clause  2  of  port/4:  Afaddxor] 

[WARNING:  Singleton  variables,  clause  3  of  port/4:  Afaddxor] 

[WARNING:  Singleton  variables,  clause  4  of  port/4:  Afaddxor] 

[WARNING:  Singleton  variables,  clause  5  of  port/4:  Afaddxor] 

[WARNING:  Singleton  variables,  clause  1  of  part/3:  Afaddxor] 

[WARNING:  Singleton  variables,  clause  2  of  part/3:  Afaddxor] 

[WARNING:  Singleton  variables,  clause  3  of  part/3:  Afaddxor] 

[WARNING:  Singleton  variables,  clause  4  of  part/3:  Afaddxor] 

[WARNING:  Singleton  variables,  clause  5  of  part/3:  Afaddxor] 

[faddxor.pro  consulted  1.183  sec  2,368  bytes] 

[consulting  /usr/u8ers/gce90d/kspark8/i5jan91/boole2.pro. . .] 

[WARNING:  Singleton  variables,  clause  1  of  remove.x.1/3:  X] 

[WARNING:  Singleton  variables,  clause  2  of  remove_x_l/3:  X] 

[WARNING:  Singleton  variables,  clause  3  of  reznove_x_l/3:  Arg2] 

[WARNING:  Singleton  variables,  clause  4  of  reoove_x_l/3:  Arg,  Argl,  Arg2] 

[WARNING:  Singleton  variables,  clause  5  of  remove_x_l/3:  Arg2] 

[WARNING:  Singleton  variables,  clause  6  of  remove_x_l/3:  Arg2] 

[WARNING:  Singleton  variables,  clause  1  of  remove_x_0/3:  X] 

[WARNING:  Singleton  variables,  clause  2  of  remove_x_0/3:  X] 

[WARNING:  Singleton  variables,  clause  3  of  remove_x_0/3 :  Arg2] 

[WARNING:  Singleton  variables,  clause  4  of  remove_x_0/3 :  Arg2] 

[WARNING:  Singleton  variables,  clause  5  of  remove_x_0/3 :  Arg2] 

[WARNING:  Singleton  variables,  clause  6  of  remove_x_0/3 :  Arg2] 

[boole2.pro  consulted  2.583  sec  6,990  bytes] 

[consulting  /usr/users/gce90d/ksparks/15jan9i/eqbeh.pro. . .] 

[WARNING:  Singleton  variables,  clause  1  of  eqb/3:  N] 

[WARNING:  Singleton  variables,  clause  2  of  eqb/3:  N] 

[WARNING:  Clauses  for  eqb/3  are  not  together  in  the  source  file] 
[eqbeh.pro  consulted  0.600  sec  1,268  bytes] 

[consulting  /usr/users/gce90d/ksparks/15jan91/verify.pro. . .] 
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[verify. pro  consulted  1.100  sec  3,004  bytes] 

[qfaddld.pro  consulted  11.800  sec  27,116  bytes] 
yes 

I  ?-  verify (f addxor) . 

>»  Attempting  to  verify  f addxor »> 

»>nand2  primitive  (needs  no  verification) »> 

>»nand2  previously  verified  »> 

>»nand2  previously  verified  »> 

»>  Attempting  to  verify  xor»> 

>»nand2  previously  verified  »> 

»>nand2  previously  verified  »> 

>»nand2  previously  verified  »> 

»>nand2  previously  verified  »> 

Applying  Rule  IB  to  out (_ 1068) 

Applying  Rule  2A  to  out (g4(_ 1068)) 
nand2’s  output  equation: 

out(g4(_1068))  :«  or(neg(in0(g4(_1068))) ,neg(inl(g4(_1068)))) 
Applying  Rule  5  to  or(neg(in0(g4(_1068))) ,neg(ini(g4(_1068)))) 
Applying  Rule  3  to  neg(in0(g4(_1068))) 

Applying  Rule  IB  to  in0(g4(_1068)) 

Applying  Rule  2A  to  out(g2(_1068)) 
nand2’s  output  equation: 

out (g2(_ 1068))  :«  or(neg(in0(g2(_1068))) ,neg(inl(g2(_1068)))) 
Applying  Rule  5  to  or(neg(in0(g2(_1068))) ,neg(inl(g2(_1068)))) 
Applying  Rule  3  to  neg(in0(g2(_1068))) 

Applying  Rule  1A  to  in0(g2(,.1068)) 

Value  of  neg(in0(_1068)) : 

neg(in0(_1068)) 

Applying  Rule  3  to  neg(inl(g2(_1068))) 

Applying  Rule  IB  to  inl(g2(_1068)) 

Applying  Rule  2A  to  out(gl(_1068)) 
nand2’s  output  equation: 

out (gl(_ 1068))  :»  or(neg(in0(gl(_1068))) ,neg(inl(gl(_1068)))) 
Applying  Rule  5  to  or(neg(in0(gl(_1068))) ,neg(ini(gl(_1068)))) 
Applying  Rule  3  to  neg(in0(gl(_1068))) 

Applying  Rule  1A  to  in0(gl(_1068)) 

Value  of  neg(in0(_1068)): 

neg(in0(_1068)) 

Applying  Rule  3  to  neg(inl(gl(_1068))) 

Applying  Rule  1A  to  ini (gl (.1068)) 

Value  of  neg(inl(_1068)) : 

neg(inl(_1068)) 

Value  of  or(neg(in0(_1068)) ,neg(inl(«1068))) : 

or (neg ( inO ( _ 1068 ) ) , neg (ini (_1068))) 

Value  of  neg(or(neg(in0(_1068)) ,neg(inl(_1068)))) : 
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and (inO(_ 1068) ,inl(_1068)) 

Value  of  or(neg(in0(.1068)),and(in0(_1068),inl(_1068))): 

or(neg(in0(_1068) ) ,and(in0 (.1068) , ini (.1068) ) ) 

Value  of  neg(or(neg(in0(_1068)),and(in0(.1068),inl(_1068)))): 

and(in0(_1068),or(neg(in0(.1068)),neg(inl(_1068)))) 

Applying  Rule  3  to  neg(inl(g4(_1068))) 

Applying  Rule  IB  to  ini(g4(_1068)) 

Applying  Rule  2A  to  out(g3(_1068)) 
nand2’s  output  equation: 

out(g3(_1068))  :*  or(neg(in0(g3(_1068))) ,neg(inl(g3(_1068)))) 

Applying  Rule  5  to  or (neg(in0 (g3 (_ 1068) )) ,neg(inl(g3(_ 1068)))) 

Applying  Rule  3  to  neg(in0(g3(_1068))) 

Applying  Rule  IB  to  in0(g3(_1068)) 

Applying  Rule  2A  to  out(gl(_1068)) 
nand2’s  output  equation: 

out (gl (.1068))  :*  or(neg(in0(gl(_1068))),neg(inl(gi(_1068)))) 

Applying  Rule  S  to  or(neg(in0(gl(_1068))) ,neg(inl(gl(.1068)))) 

Applying  Rule  3  to  neg(in0(gl(_1068))) 

Applying  Rule  1A  to  in0(gl(_1068)) 

Value  of  neg(in0(_1068)) : 

neg(in0(_1068)) 

Applying  Rule  3  to  neg(inl(gl(_1068))) 

Applying  Rule  1A  to  ini (gl (.1068)) 

Value  of  neg(inl(.l068)) : 

neg(inl(.1068)) 

Value  of  or(neg(in0(_1068)) ,neg(inl(_1068))) : 

or(neg(in0(_1068) ) ,neg(inl(.1068) ) ) 

Value  of  neg(or(neg(in0(.1068)) ,neg(inl(.1068)))) : 

and(in0(_1068) ,inl(_1068)) 

Applying  Rule  3  to  neg(ir L(g3(.1068))) 

Applying  Rule  1A  to  ini (g3(_ 1068)) 

Value  of  neg(inl(_1068)) : 

neg(inl(_1068)) 

Value  of  or(and(in0(.1068) , ini (.1068)) ,neg(inl (.1068))) : 

or(and(in0(.1068) , ini (.1068)) ,neg(ini (.1068))) 

Value  of  neg(or(and(in0(_1068),inl(_1068)),neg(inl(_1068)))): 

and(or(neg(in0(_1068)) ,neg(inl(_1068))) ,inl(_1068)) 

Value  of  or(and(in0(_1068),or(neg(in0(_1068)),neg(inl(_1068)))), 
and(or(neg(in0(_1068)) ,neg(inl(_1068))) ,inl(_1068))) : 
or(and(in0(_1068) ,or(neg(in0(_1068)) ,neg(inl(.1068)))) , 
and(or(neg(in0(.1068)) ,neg(inl(_1068))) f inl(_1068))) 

Does  or(and(in0(.1068),or(neg(in0(_1068)) ,neg(inl(_1068)))) , 

and(or(neg(in0(_1068)) ,neg(inl(_1068))) ,inl(_1068)))  = 
or(and(neg(in0(_1068)) ,inl(_1068)) , and (in0(_ 1068) ,neg(inl(_1068)))) 
or(and(in0(_1068) ,or(neg(in0(_1068)) ,neg(inl(_1068)))) f 
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and(or (nag (inO<_ 1068) ) ,neg(inl (.1068) ) ) , ini (.1068) ) )  * 
or(and(neg(in0(.1068)),inl(_1068)),and(in0(_1068),neg(inl(_1068)))) 

By  Boolean  Expansion 

<«  Success!  Behavior  of  xor  meets  its  specification. 

»>xor  previously  verified  »> 
component  list  is  [nand2] 

Applying  Rule  IB  to  outcarr/(_804) 

Applying  Rule  2A  to  out(g3(_804)) 
nand2 ’ s  output  equation: 

out(g3(_804))  :■  or(neg(in0(g3(_804))) ,neg(inl(g3(_804)))) 

Applying  Rule  5  to  or(neg(in0(g3(_804))) ,neg(ini(g3(_804)))) 

Applying  Rule  3  to  neg(in0(g3(_804))) 

Applying  Rule  IB  to  in0(g3(_804)) 

Applying  Rule  2A  to  out (gl (.804)) 
nand2’s  output  equation: 

out(gl(_804))  :«  or(neg(in0(gl(_804))) ,neg(ini(gi(_804)))) 

Applying  Rule  S  to  or(neg(in0(gl(_804))) ,neg(inl(gl(_804)))) 

Applying  Rule  3  to  neg(in0(gl(_804))) 

Applying  Rule  1A  to  in0(gl(.?04)) 

Value  of  neg(x(_804)) : 

neg (x (.804)) 

Applying  Rule  3  to  neg(inl(gl(_804))) 

Applying  Rule  1A  to  inl(gl(_804)) 

Value  of  neg(y(_804)) : 

neg (y (.804)) 

Value  of  or(neg(x(_804)) ,neg(y(_804))) : 

or (neg (x ( _804) ) , neg (y ( .804) ) ) 

Value  of  neg(or(neg(x(_804)) ,neg(y(_804)))) : 

and(x(_804) ,y (.804) ) 

Applying  Rule  3  to  neg(ini(g3(.804))) 

Applying  Rule  IB  to  ini (g3 (.804)) 

Applying  Rule  2A  to  out(g2(.804)) 
nand2’s  output  equation: 

out (g2 (.804))  :»  or(neg(in0(g2(.804))) ,neg(ini(g2(_804)))) 

Applying  Rule  5  to  or(neg(in0(g2(.804))) ,neg(inl(g2(_804)))) 

Applying  Rule  3  to  neg(in0(g2(_804))) 

Applying  Rule  1A  to  in0(g2(_804)) 

Value  of  neg(cin(_804)) : 

neg(cin(_804)) 

Applying  Rule  3  to  neg(inl(g2(.804))) 

Applying  Rule  IB  to  inl(g2(.804)) 

Applying  Rule  2B  to  out(g4(_804)) 
xor’ 8  derived  behavior: 

out(g4(_804))  :*  or(and(in0(g4(_804)) f 

or(neg(in0(g4(_804))) ,neg(inl(g4(_804))))) , 
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and(or (neg(in0(g4(.804) ) ) ,neg(inl (g4(_804) ) ) ) , 
ini (g4 (.804)))) 

Applying  Rule  5  to  or(and(in0(g4(_804)) , 

or(neg(in0(g4(_804))) ,neg(inl(g4(_804))))) , 
and(or(neg(in0(g4(_804))) ,neg(ini(g4(_804)))) , 
inl(g4(_804)))) 

Applying  Rule  4  to  and(in0(g4(_804)) , 

or (neg(in0(g4(_804) ) ) ,neg(inl (g4(_804) ) ) ) ) 
Applying  Rule  1A  to  in0(g4(_804)) 

Applying  Rule  5  to  or(neg(in0(g4(_804))) ,neg(inl(g4(_804)))) 

Applying  Rule  3  to  neg(in0(g4(_804))) 

Applying  Rule  1A  to  in0(g4(_804)) 

Value  of  neg(x(_804)) : 

neg(x(_804)) 

Applying  Rule  3  to  neg(inl (g4(_804) ) ) 

Applying  Rule  1A  to  inl(g4(_804)) 

Value  of  neg(y(_804)) : 

neg(y(^804)) 

Value  of  or(neg(x(_804)) ,neg(y(_804))) : 

or(neg(x(_804>) ,neg(y(_804))) 

Value  of  and(x(_804),or(neg(x(_804)),neg(y(_804)))): 

and(x(_804) ,or(neg(x(.804) ) ,neg(y (.804) ) ) ) 

Applying  Rule  4  to  and(or(neg(in0(g4(.804))) ,neg(inl(g4(.804)))) , 

inl(g4(_804))) 

Applying  Rule  5  to  or(neg(in0(g4(.804))) ,neg(inl(g4(_804)))) 

Applying  Rule  3  to  neg(in0(g4(_804))) 

Applying  Rule  1A  to  in0(g4(_804)) 

Value  of  neg(x(_804)) : 

neg(x(_804)) 

Applying  Rule  3  to  neg(inl(g4(_804))) 

Applying  Rule  1A  to  inl(g4(_804)) 

Value  of  neg(y(_804)) : 

neg(y(_804)) 

Value  of  or(neg(x(_804)),neg(y(_804))): 

or(neg(x(_804)) ,neg(y(.804))) 

Applying  Rule  1A  to  ini (g4 (.804)) 

Value  of  and(or(neg(x(.804)) ,neg(y(_804))) ,y(.804)) : 

and(or(neg(x(_804)) ,neg(y(_804))) ,y(_804)) 

Value  of  or(and(x(_804) ,or (neg(x(_804) ) ,neg(y (.804) ) ) ) , 
and(or (neg(x(.804) ) ,neg(y (.804) ) ) ,y(_804))) : 
or(and(x(_804) ,or(neg(x(_804)) ,neg(y(.804)))) , 
and(or(neg(x(_804) ) ,neg(y(_804) ) ) ,y (.804) ) ) 

Value  of  neg(or(and(x(.804) ,or(neg(x(_804)) ,neg(y(_804)))) , 

and(or(neg(x(_804) ) ,neg(y(.804) ) ) ,y(.804) ) ) ) : 
and(or(neg(x(_804)) ,and(x(_804) ,y(_804))) , 
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or(and(x(_804) ,y(_804)) ,neg(y(_804)))) 

Value  of  or(neg(cin(_804)), 

and(or(neg(x(_804)) ,and(x(_804) ,y(_804))) , 
or(and(x(_804) ,y(_804)) ,neg(y(„804))))) : 
or(neg(cin(.804>) , 

and(or(neg(x(_804)) ,and(x(_804) ,y(_804))) , 
or (and(x(_804) ,y (.804) ) ,neg(y (.804) ) ) ) ) 

Value  of  neg(or(neg(cin(_804)) , 

and(or(neg(x(_804)) ,and(x(_804) ,y(_804))) , 
or(and(x(_804) ,y(_804)) ,neg(y(_804)))))) : 
and(cin(_804) ,or(and(x(_804) , 

or(neg(x(_804) ) ,neg(y(_804) ) ) ) , 
and(or(neg(x(_804)) ,neg(y(_804))) , 
y(.804))» 

Value  of  or(and(x(_804) ,y(_804)) , 
and(cin(_804) , 

or(and(x(_804) , or (neg (x (.804)) ,neg(y(_804)))) , 
and(or(neg(x(_804) ) ,neg(y (_804) ) ) ,y (_804) ) ) ) ) : 
or (and(x(_804) ,y(_804) ) , 
and(cin(_804) , 

or(and(x(_804) ,or(neg(x(_804)) ,neg(y(_804)))) , 
and (or (neg (x ( .804) ) ,neg(y (.804) ) ) ,y (.804) ) ) ) ) 

Does  or(and(x(_804) ,y(.804)) , 
and(cin(_804) , 

or(and(x(_804) ,or(neg(x(_804)) ,neg(y(_804)))) , 
and(or(neg(x(_804) ) ,neg(y(_804) ) ) ,y (_804) ) ) ) )  = 
or(and(x( .804) ,y (_804) ) ,and(cin(_804) ,xor(x(_804) ,y(_804) ) ) ) 
or (and(x(_804) ,y (_804) ) , 
and(cin(_804) , 

or(and(x(_804) ,or(neg(x(_804) ) ,neg(y (.804) ) ) ) , 
and(or(neg(x(_804) ) ,neg(y (.804) ) ) ,y (_804) ) ) ) )  = 
or(and(x(_804),y(_804)),and(cin(_804),xor(x(_804),y(_804)))) 

By  Boolean  Expansion 
Applying  Buie  IB  to  outsum(_804) 

Applying  Rule  2B  to  out(g5(_804)) 
xor's  derived  behavior: 

out(g5(_804))  :«  or(and(in0(g5(.804>) , 

or (neg(in0(g5(_804) ) ) , neg (ini (g5 (_804) ) ) ) ) , 
and (or (neg ( inO (g5 (_804) ) ) ,neg ( ini (g5 ( _804) ) ) ) , 
ini (g5 (.804)))) 

Applying  Rule  5  to  or(and(in0(g5(_804)) , 

or(neg(in0(g5(_804))) ,neg(inl(g5(_804))))) , 
and(or (neg(in0(g5(_804) ) ) ,neg(inl(g5(_804)))) , 
ini(g5(_804)))) 

Applying  Rule  4  to  and(in0(g5(_804)) , 
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or (neg ( inO (g5 (_804) ) ) ,neg(inl (g5(_804) ) ) ) ) 
Applying  Rule  IB  to  in0(g5(_804)) 

Applying  Rule  2B  to  out(g4(_804)) 
xor’s  derived  behavior: 

out(g4(_804))  or(and(in0(g4(_804)) , 

or(neg(in0(g4(_804) ) ) ,neg(inl (g4(_804) ) ) ) ) , 
and(or(neg(in0(g4(_804) ) ) ,neg(inl (g4 (_804) ) ) ) , 
ini<g4(.804)))> 

Applying  Rule  5  to  or(and(in0(g4(_804)) , 

or(neg(in0(g4(_804) ) ) ,neg(ini(g4(_804) ) ) ) ) , 
and(or(neg(in0(g4(_804))) ,neg(inl(g4(_804)))) , 
inl(g4(_804)))) 

Applying  Rule  4  to  and(in0(g4(_804)) , 

or(neg(in0(g4(_804))),neg(inl(g4(_804))))) 
Applying  Rule  1A  to  in0(g4(_804)) 

Applying  Rule  5  to  or(neg(in0(g4(_804))) ,neg(ini(g4(_804)))) 

Applying  Rule  3  to  neg(in0(g4(_804))) 

Applying  Rule  1A  to  in0(g4(_804)) 

Value  of  neg(x(_804)) : 

neg(x(_804)) 

Applying  Rule  3  to  neg(inl(g4(_804))) 

Applying  Rule  1A  to  inl(g4(_804)) 

Value  of  neg(y(_804)): 

neg(y(_804)) 

Value  of  or(neg(x(_804)) ,neg(y(_804))) : 

or(neg(x(_804)) ,neg(y(_804))) 

Value  of  and(x(_804),or(neg(x(_804)),neg(y(_804)))): 

and(x(_804) ,or(neg(x(.804) ) ,neg(y (_804) ) ) ) 

Applying  Rule  4  to  and(or(neg(in0(g4(_804))) ,neg(inl(g4(_804)))) , 

inl(g4(_804))) 

Applying  Rule  5  to  or(neg(in0(g4(_804))) ,neg(ini(g4(_804)))) 

Applying  Rule  3  to  neg(in0(g4(_804))> 

Applying  Rule  1A  to  in0(g4(_804)) 

Value  of  neg(x(_804)) : 

neg(x(_804)) 

Applying  Rule  3  to  neg(inl(g4(_804))) 

Applying  Rule  1A  to  inl(g4(_804)) 

Value  of  neg(y(_804)) : 

neg(y(_804)) 

Value  of  or(neg(x(>804)),neg(y(_804))): 

or(neg(x(_804) ) ,neg(y (_804) ) ) 

Applying  Rule  1A  to  inl(g4(_804)) 

Value  of  and(or(neg(x(_804)) ,neg(y(_804))) ,y(_804)) : 

and(or(neg(x(_804) ) ,neg(y(_804))) ,y(_804)) 

Value  of  or(and(x(_804),or(neg(x(>804)) ,neg(y(_804)))) , 
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and(or(neg(x(_804) ) ,neg(y (_804) ) ) ,y (_804) ) ) : 
or(and(x(_804) ,or(neg(x(_804) ) ,neg(y (_804) ) ) ) , 
and(or(neg(x(_804) ) ,neg(y (_804) ) ) ,y (_804) ) ) 

Applying  Rule  5  to  or(neg(in0(g5(_804))) fneg(inl(g5(_804)))) 

Applying  Rule  3  to  neg(in0(g5(_804))) 

Applying  Rule  IB  to  in0(g5(_804)) 

Applying  Rule  2B  to  out(g4(_804)) 
xor’s  derived  behavior: 

out(g4(_804))  :*  or(and(in0(g4(_804)) , 

or (neg ( inO (g4 (_804) ) ) ,neg(inl(g4(_804))))) , 
and (or (neg ( inO (g4 ( _804 ) ) ) , neg (inl(g4(_804)))), 
inl(g4(_804)))) 

Applying  Rule  5  to  or(and(in0(g4(_804)) , 

or (neg(in0(g4(_804) ) ) ,neg(inl (g4(_804) ) ) ) ) , 
and(or(neg(in0(g4(_804))) ,neg(inl(g4(_804)))) , 
inl(g4(_804)))) 

Applying  Rule  4  to  and(in0(g4(_804)) , 

or (neg(in0(g4(_804) ) ) ,neg(ini (g4(_804) ) ) ) ) 

Applying  Rule  1A  to  in0(g4(_804)) 

Applying  Rule  5  to  or(neg(in0(g4(_804))) fneg(inl(g4(_804)))) 

Applying  Rule  3  to  neg(in0(g4(„804))) 

Applying  Rule  1A  to  in0(g4(_804)) 

Value  of  neg(x(.804)) : 

neg (x(. 804)) 

Applying  Rule  3  to  neg(inl(g'(_804))) 

Applying  Rule  1A  to  inl(g4(_804)) 

Value  of  neg(y(_804)) : 

neg(y(_804)) 

Value  uf  or(neg(x(_804)) ,neg(y(_804))) : 

or(neg(x(_804)) ,neg(y(_804))) 

Value  of  and(x(_804) ,or(neg(x(_804)) ,neg(y(_804)))) : 

and(x(_804) ,or(neg(x(_804) ) ,neg(y(_804) ) ) ) 

Applying  Rule  4  to  and(or(neg(in0(g4(_804))) ,neg(inl(g4(_804)))) ,inl(g4(_804))) 
Applying  Rule  5  to  or(neg(in0(g4(_804))) ,neg(ini(g4(_804)))) 

Applying  Rule  3  to  neg(in0(g4(_804))) 

Applying  Rule  1A  to  in0(g4(_804)) 

Value  of  neg(x(_804)) : 

neg(x(_804)) 

Applying  Rule  3  to  neg(inl(g4(_804))) 

Applying  Rule  1A  to  inl(g4(_804)) 

Value  of  neg(y(_804)) : 

neg(y(_804)) 

Value  of  or (neg (x( .804)) ,neg(y(_804))) : 

or(neg(x(_804)) ,neg(y(_804))) 

Applying  Rule  iA  to  inl(g4(_804)) 
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Value  of  and(or(neg(x(_804)),neg(y(_804))),y(_804)): 

and(or(neg(x(_804)) ,neg(y(_804))) ,y(_804)) 

Value  of  or(and(x(_804),or(neg(x(_804)),neg(y(_804)))), 
and(or(neg(x(_804)) ,neg(y(_804))) ,y(_804))) : 
or(and(x(_804)  ,or(neg(x(.804)) ,neg(y(_804)))) , 
and(or(neg(x(_804)),neg(y(_804))),y(.804))) 

Value  of  neg(or(and(x(_804),or(neg(x(_804)),neg(y(_804)))), 

and(or(neg(x(_804)) ,neg(y(_804))) ,y<_804)))) : 
and(or(neg(x<_804)) ,and(x(_804) ,y(_804))) , 
or(and(x(_804) ,y(_804)) ,neg(y(_804)))) 

Applying  Rule  3  to  neg(inl(g5(_804))) 

Applying  Rule  1A  to  inl(g5(_804)) 

Value  of  neg(cin(_804)) : 

neg(cin(_804)) 

Value  of  or(and(or(neg(x(_804)) ,and(x(_804) ,y(_804))) , 
or (and (x (.804) ,y(_804)) ,neg(y(_804)))) , 
neg(cin(Ji04))) : 

or(and(or(neg(x(_804)) ,and(x(_804) ,y(_804))) , 
or(and(x(_804) ,y(_804)) ,neg(y(_804)))) , 
neg(cin(_804))) 

Value  of  and(or(and(x(_804),or(neg(x(.804)),neg(y(.804)))), 
and(or(neg(x(_804) ) ,neg(y(.804) )) ,y (.804) ) ) , 
or(and(or(neg(x(.804)) ,and(x(.804) ,y(_804))) , 
or(and(x(_804)  ,y(_804))  ,neg(y(.804)))) , 
neg(cin(_804) ) ) ) : 

and (or ( and (x ( _804) , or(neg (x ( _804) ) , neg (y(_804)))), 
and(or(neg(x(_804)) ,neg(y(_804))) ,y(_804))) , 
or(and(or(neg(x(_804)) ,and(x(_804) ,y(„804))) , 
or(and(x(_804) ,y(_804)) ,neg(y(.804)))) , 
neg(cin(_804)))) 

Applying  Rule  4  to  and(or(neg(in0(g5(_804))) ,neg(ini(g5(_804)))) , 

ini (g5 (.804))) 

Applying  Rule  5  to  or(neg(in0(g5(_804))) ,neg(ini(g5(_804)))) 

Applying  Rule  3  to  neg(in0(g5(.804))) 

Applying  Rule  IB  to  in0(g5(_804)) 

Applying  Rule  2B  to  out(g4(_804)) 
xor’s  derived  behavior: 

out(g4(_804))  :*  or(and(in0(g4(_804)) , 

or(neg(in0(g4(_804))) ,neg(ini(g4(_804))))) , 
and(or(neg(in0(g4(.804) ) ) ,neg(inl (g4(_804) ) ) ) , 
inl(g4(_804)))) 

Applying  Rule  5  to  or(and(in0(g4(_804)) , 

or(neg(in0(g4(_804))),neg(inl(g4(_804))))) , 
and(or(neg(in0(g4(_804))) ,neg(inl(g4(_804)))) , 
inl(g4(_804)))) 
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Applying  Rule  4  to  and(in0(g4(.804)) , 

or (neg(in0(g4(_804) ) ) ,neg(inl (g4(_804) ) ) ) ) 
Applying  Rule  1A  to  in0(g4(_804)) 

Applying  Rule  5  to  or(neg(in0(g4(_804))) ,neg(ini(g4(_804)))) 
Applying  Rule  3  to  neg(in0(g4(_804))) 

Applying  Rule  1A  to  in0(g4(_804)) 

Value  of  neg(x(_804)) : 

neg(x(_804)) 

Applying  Rule  3  to  neg(inl(g4(_804))) 

Applying  Rule  1A  to  inl(g4(_804)) 

Value  of  neg(y(_804)) : 

neg(y(_804)) 

Value  of  or(neg(x(_804)) ,neg(y(_804))) : 

or(neg(x(_804)) ,neg(y(_804))) 

Value  of  and(x(_804) ,or(neg(x(_804)) ,neg(y(_804)))) : 

and(x(_804) ,or(neg(x(_804) ) ,neg(y (.804) ) ) ) 

Applying  Rule  4  to  and(or(neg(in0(g4(_804))) ,neg(inl(g4(_804)))) , 

inl(g4(_804))) 

Applying  Rule  5  to  or(neg(in0(g4(_804))) ,neg(inl(g4(_804)))) 
Applying  Rule  3  to  neg(in0(g4(_804))) 

Applying  Rule  1A  to  in0(g4(_804)) 

Value  of  neg(x(.804)): 

neg(x(_804)) 

Applying  Rule  3  to  neg(ini(g4(_804))) 

Applying  Rule  1A  to  inl(g4(_804)) 

Value  of  neg(y(.804)) : 

neg(y(_804)) 

Value  of  or(neg(x(_804)),neg(y(.804))): 

or (neg(x(_804) ) ,neg(y (.804) ) ) 

Applying  Rule  1A  to  inl(g4(_804)) 

Value  of  and(or(neg(x(.804)),neg(y(_804))),y(.804)): 

and(or (neg(x(_804) ) ,neg(y(„804))) ,y(_804)) 

Value  of  or(and(x(_804),or(neg(x(_804)),neg(y(_804)))), 
and(or(neg(x(_804)) ,neg(y(_804))) ,y(_804))) : 
or(and(x(_804) ,or(neg(x(_804)) ,neg(y(_804)))) , 
and(or(neg(x(_804)),neg(y(_804))) ,y(.804))) 

Value  of  neg(or(and(x(_804),or(neg(x(_804)),neg(y(_804)))) , 
and(or(neg(x(_804) ) ,neg(y(_804) ) ) ,y (.804) ) ) ) : 
and(or(neg(x(_804)) ,and(x(_804) ,y(.804))) , 
or(and(x(_804),y(_804)),neg(y(_804)))) 

Applying  Rule  3  to  neg(inl(g5(_804))) 

Applying  Rule  1A  to  ini (g5 (.804)) 

Value  of  neg(cin(_804)) : 

neg(cin(_804)) 

Value  of  or(and(or(neg(x(_804)),and(x(_804),y(.804))), 


or(and(x(_804) ,y(_804)) ,neg(y(_804)))) , 
neg(cin(_804))) : 

or(and(or(neg(x(_8C4) ) ,and(x(_804) ,y(_804) ) ) , 
or(and(x(.804) ,y(_804)) ,neg(y(.804)))) , 
neg(cin(.804))) 

Applying  Rule  1A  to  inl(g5(_804)) 

Value  of  and(or(and(or(neg(x(_804)),aad(x(_804),y(_804))), 

or(and(x(_804)  ,y(.804)) ,neg(y(_804)))) , 
neg(cin(_804))) , 
cin(_804)) : 

and(or(and(or(neg(x(_804)) ,and(x(.804) ,y(_S04))) , 
or(and(x(.804) ,y(_804)) ,neg(y(_804)))) , 
neg(cin(_804))) , 
cin(.804)) 

Value  of  or(and(or(and(x(_804) ,or(neg(x(_804) ) ,neg(y(_804) ) ) ) , 
and (or (neg (x (_804) ) ,neg(y (.804) ) ) ,y (.804) ) ) , 
or(and(or(neg(x(_804)) ,and(*(_804) ,y(_804))) , 
or(and(x(_804) ,y(.804) ) ,neg(y (.804) ) ) ) , 
neg(cin(_804) ) ) ) , 

and(or (and(or (neg(x(_804) ) ,and(x(_804) ,y(_804) ) ) , 
or(and(x(_804) ,y(_804) ) ,neg(y (.804) ) ) ) , 
neg(cin(_804))) , 
cin(.804))) : 

or(and(or(and(x(.804) ,or(neg(x(.804) ) ,neg(y (.804) ))), 
and(or (neg(x(_804) ) ,neg(y(.804))) ,y(_804))) , 
or(and(or(neg(x(.804)) ,and(x(.804) ,y(_804))) , 
or(and(x(_804),y(_804)),neg(y(.804))))t 
neg(cin(.804) ) ) ) , 

and(or(and(or(neg(x(.804)) ,and(x(.804) ,y(.804))) , 
or(and(x(_804) ,y (.804) ) ,neg(y (.804) ) ) ) , 
neg(cin(_804))), 
cin(_804))) 

Does  or(and(or(and(x(_804) ,or(neg(x(.804)) ,neg(y(_804)))) , 
and(or(neg(x(_804) ) ,neg(y(_804) ) ) ,y (.804) ) ) , 
or ( and (or (neg (x ( .804) ) , and(x(_804) ,y (.804) ) ) f 
or(and(x(_804) ,y(.804)) ,neg(y(.804)))) , 
neg(cin(_804) ) ) ) , 

and(or(and(or(neg(x(.804)) ,and(x(_804) ,y(_804))) , 
or(and(x(_804) ,y(_804)) ,neg(y(_804)))) , 
neg(cin(_804))) , 
cin(_804)))  * 

xor (xor (x (.804) , y (.804) ) , cin( .804) ) 
or(and(or(and(x(_804) ,or (neg(x(_804) ) ,neg(y (.804) ) ) ) , 
and (or (neg (x (.804)) ,neg(y(_804))) ,y(.804))) , 
or(and(or(neg(x(_804)) ,and(x(_804) ,y(.804))) , 
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or(and(x(_804) ,y(_804)) ,neg(y(_804)))) , 
neg(cin(_804)))) , 

and(or(and(or(neg(x(_804)) ,and(x(_804) ,y(_804))) , 
or(and(x(_804) ,y(_804)) ,nog(y(_804)))) , 
neg(cin(_804))), 
cin(_804)))  * 

xor(xor(x(_804) ,y(_804)) ,cin(_804)) 

By  Boolean  Expansion 

«<  Success!  Behavior  of  faddxor  meets  its  specification, 
yes 

I  ?-  halt. 
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/*************4^********************************************/ 

/*  This  fils  loads  tha  appropriats  files  to  verify  a  */ 

I*  a  fulladder  with  PROLOG-i.  This  is  invoked  by  typing  */ 

/*  [*a:f addload*] .  */ 

/  ***********************************************************  / 

?-  [*a:ops* , *a:eval* , *a:derbah* , *a:derstate* , *a:xor* , *a:faddxor’] . 
?-  [*a:boole2* , *a:eqbeh* , *a:verify*]  . 

Sample  run  for  a  full-adder  circuit  on  PROLOG-? : 

B : \>prolog 

+ - + 

I  MS-DOS  Prolog- 1  Version  2.2  I 

I  Copyright  1983  Serial  number:  0001213  I 
I  Expert  Systems  Ltd.  I 

I  Oxford  U.K.  I 

+ - + 

?-  [* a:f addload*] . 
a: ops  consulted. 
a:eval  consulted. 
a:derbeh  consulted. 
a:derstate  consulted. 
a:xor  consulted. 
a:faddxor  consulted. 
a:boole2  consulted. 
a:eqbeh  consulted, 
a: verify  consulted. 
a:f addload  consulted. 

?-  verify (faddxor) . 

»>  Attempting  to  verify  faddxor»> 

>»nand2  primitive  (needs  no  verification)  >>> 

»>nand2  previously  verified  »> 

»>nand2  previously  verified  »> 

»>  Attempting  to  verify  xor>» 

>»nand2  previously  verified  »> 

>»nand2  previously  verified  »> 

»>nand2  previously  verified  >» 

>>>nand2  previously  vexified  »> 

Applying  Rule  IB  to  out(_109) 

Applying  Rule  2A  to  out(g4(_109)) 
nand2*s  output  equation: 

out(g4(_109))  :*  or(neg(in0(g4(_109))),neg(inl(g4(_109)))) 
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Applying  Rule  5  to  or(neg(in0(g4(_109))) ,neg(inl(g4(_109)))) 
Applying  Rule  3  to  neg(in0(g4(_109))) 

Applying  Rule  IB  to  in0(g4(_109)) 

Applying  Rule  2A  to  out(g2(_109)) 
nand2’s  output  equation: 

out(g2(_109))  :■  or(neg(in0(g2(_109))),neg(inl(g2(_i09)))) 
Applying  Rule  5  to  or(neg(in0(g2(_109))) ,neg(inl(g2<_109)))) 
Applying  Rule  3  to  neg(in0(g2(_109))) 

Applying  Rule  1A  to  in0(g2(_109)) 

Value  of  neg(in0(_109)) : 

neg(in0(_109)) 

Applying  Rule  3  to  neg(ini(g2(_109))) 

Applying  Rule  IB  to  inl(g2(_109)) 

Applying  Rule  2A  to  out(gl(_109)) 
nand2’s  output  equation: 

out(gl(_109))  :«  or(neg(in0(gl(_109))},neg(inl(gi(_109)))) 
Applying  Rule  5  to  or(neg(in0(gl(_109))) ,neg(inl(gl(_109)))) 
Applying  Rule  3  to  neg(in0(gl(_109))) 

Applying  Rule  1A  to  in0(gl(_109)) 

Value  of  neg(in0(_109)) : 

neg(in0(_109)) 

Applying  Rule  3  to  neg(inl(gl(_109))) 

Applying  Rule  1A  to  inl(gl(_i09)) 

Value  of  neg(inl(.109)) : 

nog(inl(_109)) 

Value  of  or(neg(in0(_109)) ,neg(inl(_109))) : 

or(neg(in0(_109) ) ,neg(inl (_109) ) ) 

Value  of  neg(or(neg(in0(_109)) ,neg(inl(_109)))) : 
and(in0(_109) , ini (.109)) 

Value  of  or(neg(in0(_109)),and(in0(_109),inl(_109))): 

or(neg(in0(.109)),and(in0(_109),inl(_109)')) 

Value  of  neg(or(neg(in0(_109)) ,and(in0(_109) ,ini(_109)))) : 

and(in0(_109) ,or(nog(in0(_109)) ,neg(inl(_109)))) 
Applying  Rule  3  to  neg(inl(g4(_109))) 

Applying  Rule  IB  to  ini(g4(_109)) 

Applying  Rule  2A  to  out(g3(_109)) 
nand2’s  output  equation: 

out(g3(_109))  :«  or(neg(in0(g3(_109))),neg(inl(g3(_109)))) 
Applying  Rule  5  to  or(neg(in0(g3(_109))) ,neg(ini(g3(_109)))) 
Applying  Rule  3  to  neg(in0(g3(_109))) 

Applying  Rule  IB  to  in0(g3(_109)) 

Applying  Rule  2A  to  out(gl(_109)) 
nand2’s  output  equation: 

out(gl(_109))  :■  or(neg(in0(gl(_109) ) ) ,neg(ini(gl(_109) ) ) ) 
Applying  Rule  5  to  or(neg(in0(gl(_109))) ,neg(inl(gl(_109)))) 
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Applying  Rule  3  to  neg(in0(gl(_109))) 

Applying  Rule  iA  to  in0(gl(_109)) 

Value  of  neg(in0(.109)) : 

neg(in0C_109)) 

Applying  Rule  3  to  neg(ini(gl(_109))) 

Applying  Rule  1A  to  inl(gl(_109)) 

Value  of  neg(inl(_109)) : 

neg(inl(_109)) 

Value  of  or(neg(in0(.109)) ,neg(inl(_109))) : 

or(neg(in0(_109) ) ,neg(ini (_109) ) ) 

Value  of  neg(or(neg(in0(_109)) ,neg(inl(_109)))) : 

and(in0(_109) , ini (.109)) 

Applying  Rule  3  to  neg(inl(g3(_109))) 

Applying  Rule  1A  to  ini (g3 (.109)) 

Value  of  neg(inl(_109)) : 

neg(inl(_109)) 

Value  of  or(and(in0(.109),inl(.109)),neg(inl(_109))): 

or(and(in0(_109) ,inl(.109)) ,neg(ini(.109))) 

Value  of  neg(or(and(in0(_109) ,inl(.109)) ,neg(inl(_109)))) : 

and(or(neg(in0(_109)) ,neg(inl(„109))) ,inl(_109)) 

Value  of  or(and(in0(.109),or(neg(in0(.109)),neg(inl(_109)))), 
and(or (neg(in0(.109) ) ,neg(inl (.109) ) ) , ini (.109) ) ) : 
or(and(in0(_109) tor(neg(in0(.109)) ,neg(inl(_109)))) , 
and (or (neg(in0(.109) ) ,neg(inl (.109) ) ) , ini (.109) ) ) 

Does  or ( and ( inO ( . 109) , or (neg ( inO (_ 109) ) f neg ( ini (_ 109) ) ) ) , 

and(or(neg(in0(_109)) ,neg(inl(_109))) ,inl(_109)))  ■ 
or ' and (neg ( inO ( _ 109) ) , inl(.109) ) ,and(in0(_109) ,neg(inl (.109) ) ) ) 
or(ana(in0(.109) ,or(neg(in0(_109)) ,neg(inl(.109)))) , 
and(or(neg(in0(.109)) ,neg(inl(_109))) ,inl(_109)))  = 
or(and(neg(in0(_109)) ,inl(_109)) ,and(in0(_109) ,neg(inl(_109)))) 

By  Boolean  Expansion 

«<  Success!  Behavior  of  xor  meets  its  specification. 

>»xor  previously  verified  >>> 

Applying  Rule  IB  to  outcarry(.115) 

Applying  Rule  2A  to  out(g3(_115)) 
nand2’s  output  equation: 

out(g3(_115))  :*  or(neg(in0(g3(.115))) ,neg(inl(g3(.115)))) 
Applying  Rule  5  to  or(neg(in0(g3(_115))) ,neg(inl(g3(_115)))) 

Applying  Rule  3  to  neg(in0(g3(_115))) 

Applying  Rule  IB  to  in0(g3(_115)) 

Applying  Rule  2A  to  out(gl(_115)) 
nand2’s  output  equation: 

out(gl(_115))  :*  or(neg(in0(gl(_115))) ,neg(ini(gi(_115)))) 
Applying  Rule  S  to  or(neg(in0(gl(_115))) ,neg(ini(gi(_115)))) 

Applying  Rule  3  to  neg(in0(gl(_115))) 
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Applying  Rule  1A  to  in0(gl(_115)) 

Value  of  neg(x(_115)) : 

neg(x(.115)) 

Applying  Rule  3  to  neg(inl(gl(_115))) 

Applying  Rule  1A  to  ini (gl (.116)) 

Value  of  neg(y(_116)): 

neg(y(_115)) 

Value  of  or(neg(x(_115)),neg(y(_115))): 

or(neg(x(_115)) ,neg(y(_115))) 

Value  of  neg(or(neg(x(_115)),neg(y(_115)))): 

and(x(_115) ,y(_115)) 

Applying  Rule  3  to  neg(inl(g3(_115))) 

Applying  Rule  IB  to  inl(g3(_115)) 

Applying  Rule  2A  to  out(g2(_116)) 
nand2’s  output  equation: 

out (g2 (.115))  :«  or(neg(in0(g2(.115)))fneg(inl(g2(_115)))) 

Applying  Rule  5  to  or(neg(in0(g2(_115))) ,neg(inl(g2(.115)))) 

Applying  Rule  3  to  neg(in0(g2(_115))) 

Applying  Rule  1A  to  in0(g2(_115)) 

Value  of  neg(cin(.116)) : 

neg(cin(_115)) 

Applying  Rule  3  to  neg(inl(g2(.US))) 

Applying  Rule  IB  to  lnl(g2(.115)) 

Applying  Rule  2B  to  out(g4(.HS)) 
xor’s  derived  behavior: 

out(g4(_115))  :■  or(and(in0(g4(_115)), 

or (neg(in0(g4(.115) ) ) ,neg(inl (g4(.115) ) ) ) ) , 
and(or(neg(in0(g4(_115) ) ) ,neg(inl (g4(_115) ) ) ) , 
inl(g4(_115)))) 

Applying  Rule  5  to  or(and(in0(g4(.115)) , 

or(neg(in0(g4(_115) ) ) ,neg(inl(g4(_115) ) ) ) ) , 
and(or(neg(in0(g4(_115))),neg(inl(g4(_115)))), 
inl(g4(.116)))) 

Applying  Rule  4  to  and(in0(g4(_116)) , 

or(neg(in0(g4(_115))) ,neg(inl(g4(_115))))) 
Applying  Rule  1A  to  in0(g4(_115)) 

Applying  Rule  5  to  or(neg(in0(g4(_115))) ,neg(ini(g4(_115)))) 

Applying  Rule  3  to  neg(in0(g4(_115))) 

Applying  Rule  1A  to  in0(g4(_115)) 

Value  of  neg(x(_115)) : 

neg(x(_115)) 

Applying  Rule  3  to  neg(ini(g4(_115))) 

Applying  Rule  1A  to  inl(g4(_115)) 

Value  of  neg(y(_115)): 

neg(y(_H6)) 
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Value  of  or(neg(x(_115)) ,neg(y(_115))) : 

or(neg(x(_115)),neg(y(_115))) 

Value  of  and(x(_115) ,or(neg(x(_115)) ,neg(y(_115)))) : 

and(x(_115)  ,or(neg(x(_ilo)) ,neg(y(_115)))) 

Applying  Rule  4  to  and(or(neg(in0(g4(_115))) ,neg(inl(g4(_115)))) , 

inl(g4(_116))) 

Applying  Rule  5  to  or(neg(inO(g4Cll5)))  ,neg(inl(g4(_115)))) 

Applying  Rule  3  to  neg(in0(g4(_115))) 

Applying  Rule  1A  to  in0(g4(_115)) 

Value  of  neg(x(_115)) : 

neg(x(_115)) 

Applying  Rule  3  to  neg(inl(g4(_115))) 

Applying  Rule  1A  to  inl(g4(_115)) 

Value  of  neg(y(_115)) : 

neg(y(_115)) 

Value  of  or(neg(x(_li5)) ,neg(y(_115))) : 

or(neg(x(_115)) ,neg(y(_115))) 

Applying  Rule  1A  to  inl(g4(..115)) 

Value  of  and(or(neg(x(_115)) ,neg(y(_115))) ,y(_115)) : 

and (or (neg (x  (_  1 15) ) ,neg(y(_115) ) ) ,y(_ 115) ) 

Value  of  or(and(x(_115),or(neg(x(_115)),neg(y(_115)))), 
and(or(neg(x(_115)) ,neg(y(_115))) ,y(_115))) : 
or(and(x(_115),or(neg(xLllS)),neg(yLil5)))) , 
and(or(neg(x(„115)),neg(y(_115))),y(_115))) 

Value  of  neg(or(and(x(_115) ,or(neg(x(_116)) „neg(y(_115)))) , 

and(or(neg(x(_115) ) ,neg(y (_11S) ) ) ,y(_115) ) ) ) : 
and(or(neg(x(_115)) ,and(x(_115) ,y(_115))) , 
or(and(x(_115) ,y(_115)) ,neg(y(_115)))) 

Value  of  or(neg(cin(_115)) ,and(or(neg(x(_115)) ,and(x(_115) ,y(_115))) , 

or(and(x(_ll5)  ,y(_115)) ,neg(y(_115))))) : 
or(neg(cin(_115)) ,and(or(neg(x(_115)) ,and(x(_115) ,y(_115))) , 

or(and(x(_115),y(_115)),neg(y(_115))))) 

Value  of  neg(or(neg(cin(_115)) , 

and (or (neg (x(„ 115) ) ,and(x(_115) ,y (_115) ) ) , 
or(and(x(_115) ,y(_115)) ,neg(y(_115)))))) : 
and(cin(_115) ,or(and(x(_115) ,or(neg(x(_115)) ,neg(y(_115)))) , 
and(or(neg(x(_115)),neg(y(_115))) ,y(_115)))) 
Value  of  or(and(x(_115) ,y(_115)) , 

and(cin(_115) ,or(and(x(_115) ,or(neg(x(_115)) ,neg(y(_115)))) , 

and(or(neg(x(_115)),neg(y(_115))) ,y(_115))))) 
or(and(x(_115) ,y(_115) ) , 

and(c.in(_115) ,or(and(x(_115) ,or(neg(x(_115)) ,neg(y(_115)))) , 

and (or (neg (x(_ 115)) ,neg(y(_115))) ,y(_115))))) 

Does  or(and(x(_115) ,y(_115)) , 

and(cin(_115) ,or(and(x(_115) ,or(neg(x(_115) ) ,neg(y (.115) ) ) ) , 
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and(or(neg(x(_115)) ,neg(y(_115))) ,y(_115)))))  * 
or(and(x(„115) ,y(_115)) ,and(cin(_ilS) ,xor(x(_ilS) ,y(_115)))) 
or(and(x(.115) ,y(_115)) , 

and(cin(_115) ,or(and(x(_115) ,or (neg(x(_115) ) ,neg(y (.115) ) ) ) , 

and(or(neg(xCllS)) ,neg(y(_115))) ,y(_115)))))  = 
or(and(x(_115) ,y(_115)) ,and(cin(_115) ,xor(x(_115) ,y(_115)))) 

By  Boolean  Expansion 
Applying  Rule  IB  to  outsum(_114) 

Applying  Rule  2B  to  out(g5(_114)) 
xor ’ 8  derived  behavior: 

out(g6(_114))  :*  or(and(in0(g5(.114)) , 

or(neg(in0(g5(_114))) ,neg(ini(g5(_114))))) , 
and (or (neg ( inO (gS ( _ 1 14) ) ) , neg ( ini (g5 ( _ 1 14) ) ) ) , 
inl(g5(_114)))) 

Applying  Rule  5  to  or(and(in0(g5(_114)) , 

or(neg(in0(g5(_ii4))) ,neg(inl(g5(_114))))) , 
and(or(neg(in0(g5(_114))) ,neg(inl(g5(_114)))) , 
inl(gSLll4)))) 

Applying  Rule  4  to  and(in0(g5(_114)) , 

or (neg ( inO (g5 (_ 1 14) ) ) , neg (inl(g5(_114))))) 
Applying  Rule  IB  to  in0(g5(_114)) 

Applying  Rule  2B  to  out(g4(_114)) 
xor’s  derived  behavior: 

out(g4(_114))  :«  or(and(in0(g4(.114)) , 

or (neg ( inO (g4 (_ 1 14) ) ) ,neg(inl (g4(_114) ) ) ) ) , 
and(or(neg(in0(g4(_114) ) ) ,neg(inl (g4(_114) ) ) ) , 
inl(g4(_114)))) 

Applying  Rule  5  to  or(and(in0(g4(_114)) , 

or(neg(in0(g4(_114))) ,neg(ini(g4(_114))))) , 
and(or(neg(in0(g4(_114))) ,neg(ini(g4(_114)))) , 
inl(g4(_114)))) 

Applying  Rule  4  to  and(in0(g4(_114)) , 

or(neg(in0(g4(_114))),neg(inl(g4(_114))))) 
Applying  Rule  1A  to  in0(g4(_114)) 

Applying  Rule  5  to  or(neg(in0(g4(_114))) ,neg(inl(g4(_114)))) 

Applying  Rule  3  to  neg(in0(g4(_114))) 

Applying  Rule  1A  to  in0(g4(_114)) 

Value  of  neg(x(_114)) : 

neg(x(_114)) 

Applying  Rule  3  to  neg(inl(g4(_114))) 

Applying  Rule  1A  to  inl(g4(_114)) 

Value  of  neg(y(_114)) : 

neg(y(_114)) 

Value  of  or(negix(_114)) ,neg(y(_114))) : 

or(neg(x(_114)) ,neg(y(_114))) 
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Value  of  and(x(_114),or(neg(x(_114)),neg(y(_114)))): 

and(x(_114) ,or(neg(xLll4)) ,neg(y(_114)))) 

Applying  Rule  4  to  and(or(neg(in0(g4(_114))) ,neg(ini(g4(.114)))) , 

inl(g4(_114))) 

Applying  Rule  5  to  or(neg(in0(g4(_114))) ,neg(inl(g4(_114)))) 

Applying  Rule  3  to  neg(in0(g4(_114))) 

Applying  Rule  1A  to  in0(g4(_114)) 

Value  of  neg(x(_114)): 

neg(x(_114)) 

Applying  Rule  3  to  neg(inl(g4(_114))) 

Applying  Rule  1A  to  inl(g4(_114)) 

Value  of  neg(y(_114)) : 

neg(y(_114)) 

Value  of  or(neg(x(_114)),neg(y(_114))): 

or(neg(x(.il4) ) ,neg(y (_114) ) ) 

Applying  Rule  1A  to  inl(g4(_114)) 

Value  of  and(or(neg(x(_114)),neg(y(_114))),y(_114)): 

and(or(neg(x(_114)) ,neg(y(_114))) ,y(.114)) 

Value  of  or(and(xC.114),or(neg(x(_il4)),neg(y(_114)))), 
and(or(neg(x(_114) ) ,neg(y (.114) ) ) ,y (.114) ) ) : 
er(and(x(_114)  ,or(neg(x(_il4)  )  ,neg(y  (_U4)  )  )  ) , 
and(or(neg(x(_114) ) ,neg(y (.114) ) ) , y (_114) ) ) 

Applying  Rule  5  to  or(neg(in0(g5(_ii4))) ,neg(inl(gSC-114)))) 

Applying  Rule  3  to  neg(in0(g5(„114))) 

Applying  Rule  IB  to  in0(g5(_114)) 

Applying  Rule  2B  to  out(g4(_114)) 
xor’s  derived  behavior: 

cut(g4(_114))  :■  or(and(in0(g4(_114)) , 

or(neg(in0(g4(_114))),neg(inl(g4(_114))))), 
and(or (neg(in0(g4(_114) ) ) ,neg(ini (g4(_114) ) ) ) , 
inl(g4LH4)))) 

Applying  Rule  5  to  or(and(in0(g4(_114)) , 

or(neg(in0(g4(_114) ) ) ,neg(inl(g4(_114) ) ) ) ) , 
and(or(neg(in0(g4(_114))),neg(ini(g4(_114)))) , 
inl(g4(_114)))) 

Applying  Rule  4  to  and(in0(g4(_114)) , 

or(neg(in0(g4(_114) ) ) ,neg(inl (g4(_114) ) ) ) ) 
Applying  Rule  1A  to  in0(g4(_114)) 

Applying  Rule  5  to  or(neg(in0(g4(_114))) ,neg(ini(g4<_114)))) 

Applying  Rule  3  to  neg(in0(g4(_114))) 

Applying  Rule  1A  to  in0(g4(_114)) 

Value  of  neg(x(_114)): 

neg(x(_114)) 

Applying  Rule  3  to  neg(inl(g4(_114))) 

Applying  Rule  1A  to  inl(g4(„114)) 
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Value  of  neg(y(_114)) : 

neg(y(_114)) 

Value  of  or(neg(x(_114)) ,neg(y(_114))) : 

or(neg(x(_114) ) ,neg(y (_114) ) ) 

Value  of  and(x(_il4),or(neg(x(_114)),neg(y(_114)))): 

and(x(_114) ,or(neg(x(_114) ) ,neg(y (_114) ) ) ) 

Applying  Rule  4  to  and(or(neg(in0(g4(_114))) ,neg(ini(g4(_114)))) , 

inl(g4(_114))) 

Applying  Rule  5  to  or(neg(in0(g4(_114))) ,neg(inl(g4(>114)))) 
Applying  Rule  3  to  neg(in0(g4(_114))) 

Applying  Rule  1A  to  in0(g4(_114)) 

Value  of  neg(x(_114)) : 

neg(x(_114)) 

Applying  Rule  3  to  neg(inl(g4(_114))) 

Applying  Rule  1A  to  inl(g4(_114)) 

Value  of  neg(y(_114)) : 

neg(y(_114)) 

Value  of  or(neg(x(_114)) ,neg(y(_114))) : 

or(neg(x(_114) ) ,neg(y<_114) ) ) 

Applying  Rule  1A  to  inl(g4(_114)) 

Value  of  and(or(neg(x(_114)),neg(y(_114))),y(_114)): 

and(or(neg(x(_114)),neg(y(_114))),y(_114)) 

Value  of  or(and(x(_114),or(neg(x(.114)),neg(y(_114)))), 
and(or(neg(x(_114)),neg(y(_li4))),yLll4))): 
or(and(x(_114) ,or(neg(x(_114)) ,neg(y (_114) ) ) ) , 
and(or(neg(x(_114) ) ,neg(y (_114) ) ) ,y (_114) ) ) 

Value  of  neg(or(and(x(_114),or(neg(x(_114)),neg(y(_114)))), 
and(or(neg(x(.114)),neg(y(.114))),y(_114)))): 
and(or(neg(xCll4)),and(x(_114),y(_il4))), 
or(and(xCll4),y(_114)),neg(y(_114)))) 

Applying  Rule  3  to  neg(inl(g5(_il4))) 

Applying  Rule  1A  to  inl(g5(_114)) 

Value  of  neg(cin(_114)) : 

neg(cin(_114)) 

Value  of  or(and(or(neg(x(_114)),and(x(_114),y(_114))), 
or(and(x(_114) ,y(_114)) ,neg(y(_114)))) , 
neg(cin(_114))) : 

or(and(or(neg(x(_114)) ,and(x(_114) ,y(_114))) , 
or(and(x(_114) ,y(_114)) ,neg(y(_114)))) , 
neg(cin(_114))) 

Value  of  and(or(and(x(_114) ,or(neg(x(_ll4)) ,neg(y(_114)))) , 
and(or(neg(x(_114) ) , neg(y (_114) )) , 
y(_114))), 

or(and(or(neg(x(_114)) ,and(x(_114)  ,y(.U4))) , 
or(and(x(_114) ,y(_114)) , 
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neg(y(_114)))), 

neg(cin(_114)))): 

and(or(and(x(_114) ,or(neg(x(_114)) ,neg(y(_114)))) , 
and(or(neg(x(_114)) ,neg(y(_114))) , 
y(-li4))), 

or (and(or (neg(x(_114) ) , and(x(_114) , y (_114) ) ) , 
or (and(x(_114) ,y(.114) ) , 
n*g(y(-114)))) , 
neg(cin(_114)))) 

Applying  Rule  4  to  and(or(neg(in0(g5(..114))) ,neg(ini(g5(_114)))) , 

inl(g5(_114))) 

Applying  Rule  5  to  or(neg(inO(gS(_114))) ,neg(inl(g5(_114)))) 

Applying  Rule  3  to  neg(in0(g5(_114))) 

Applying  Rule  IB  to  in0(g5(_114)) 

Applying  Rule  2B  to  out(g4(_114)) 
xor's  derived  behavior: 

out(g4(..li4))  :«  or(and(in0(g4(_114)) , 

or(neg(in0(g4(_114))),neg(inl(g4(_114))))), 
and(or(neg(in0(g4(_114))),neg(inl(g4(_114)))) , 
ini(g4(_114)))) 

Applying  Rule  5  to  or(and(in0(g4(>114)) , 

or(neg(in0(g4(_114) ) ) ,neg(inl(g4(_l 14) ) ) ) ) , 
and(or(neg(in0(g4(.114))),neg(inl(g4(_114)))) , 
inl(g4(_114)))) 

Applying  Rule  4  to  and(in0(g4(_114)) , 

or(neg(in0(g4(_114) ) ) ,neg(inl (g4(_114) ) ) ) ) 
Applying  Rule  1A  to  in0(g4(_114)) 

Applying  Rule  S  to  or(neg(in0(g4(_114))) ,neg(inl(g4(_114)))) 

Applying  Rule  3  to  neg(in0(g4(_114))) 

Applying  Rule  1A  to  in0(g4(_114)) 

Value  of  neg(x(_114)) : 

neg(x(_114)) 

Applying  Rule  3  to  neg(inl(g4(_114))) 

Applying  Rule  1A  to  inl(g4(_114)) 

Value  of  neg(y(_114)) : 

neg(y(_114)) 

Value  of  or(neg(x(_114)) ,neg(y(_114))) : 

or(neg(x(_114)) ,neg(y(_114))) 

Value  of  and(x(_114) ,or(neg(x(_114)) ,neg(y(_114)))) : 

and(x(_114) ,or(neg(x(_114)) ,neg(y(_114)))) 

Applying  Rule  4  to  and(or(neg(in0(g4(_114))) ,neg(inl(g4(_114)))) , 

inl(g4(_114))) 

Applying  Rule  5  to  or(neg(in0(g4(_114))) ,neg(inl(g4(_114)))) 

Applying  Rule  3  to  neg(in0(g4(_114))) 

Applying  Rule  1A  to  in0(g4(_114)) 
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Value  of  neg(x(_114)) : 

neg(x(_114)) 

Applying  Rule  3  to  neg(inl(g4(_114))) 

Applying  Rule  1A  to  ml(g4(_114)) 

Value  of  neg(y(_114)) : 

neg(y(_114)) 

Value  of  or(neg(x(_114)),neg(y(_114))) : 

or(neg(xCll4)),neg(y(_ii4))) 

Applying  Rule  1A  to  inl(g4(_114)) 

Value  of  and(or(neg(x(_114)) ,neg(y(_ii4))) ,y(_114)) : 

and(or(neg(x(_114) ) ,neg(y (_114) ) ) ,y (_il4) ) 

Value  of  or(and(x(„114) ,or(neg(x(_114)) ,neg(y(_114)))) , 
and(or(neg(x(_114)),neg(y(_114))) ,y(_114))): 
or(and(x(_114) ,or(neg(x(_114)) ,neg(y(_ii4)))) , 
and(or(neg(x(_114)) ,neg(y(_114))) ,y<_114))) 

Value  of  neg(or(and(x(_114) ,or(neg(x(_114)) ,neg(y(_114)))) , 
and(or(neg(y(..114))  ,neg(y(_114)))  ,y(_114)))) : 
and(or(neg(x(_114)) ,and(x(_114) ,y(_ii4))) , 
or(and(x(_114) ,y(_114)) ,neg(y(_114)))) 

Applying  Rule  3  to  neg(inl(g5(_114))) 

Applying  Rule  1A  to  inl(g5(_114)) 

Value  of  neg(cin(„114)) : 

neg(cin(_114)) 

Value  of  or(and(or(neg(x(_114)),and(x(..114)ty(.,li4))), 
or (and(x(_114) ,y (_114) ) ,neg(y (_114) ) ) ) , 
neg(cin(_114))) : 

or(and(or(neg(x(_114)) ,and(x(_114) ,y(_114))) , 
or(and(x(_114) ,y(.114)) ,neg(y(_114)))) , 
neg(cin(_114))) 

Applying  Rule  1A  to  inl(g5(_114)) 

Value  of  and(or(and(or(neg(x(_114)) ,and(x(_114) ,y(_114))) , 

or(and(x(_114) ,y(_114)) ,neg(y(_114)))) , 
neg(cin(_114))) , 
cin(_114)) : 

and(or(and(or(neg(x(_114)) ,and(x(_114) ,y(_114))) , 
or(and(x(_114) ,y(_114)) ,neg(y(_114)))) , 
neg(cin(_114))) , 
cin(_114)) 

Value  of  or(and(or(and(x(_114) ,or(neg(x(_114)) ,neg(y(_114)))) , 
and(or(neg(x(_114)) ,neg(y(_114))) ,y(_li4))), 
or(and(or(neg(x(_114)) ,and(x(_114) ,y(_114))) , 
or(and(x(_114) ,y(_114) ) ,neg(y (.114) ) ) ) , 
neg(cin(_114)))) , 

and(or(and(or(neg(x(_114)),and(x(_114) fy(_114))) , 
or(and(x(_114) ,y(_114)) ,neg(y(_114)))) , 
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neg(cin(_114))), 

cin(„114))): 

or(and(or (and(x(_114) ,or(n«g(x(_114) ) ,n«g(y (.114) ) ) ) , 
and(or(neg(x(_114)) ,neg(y(_114))) ,y(_114))) , 
or(and(or(neg(x(_114)) ,and(x(_114) ,y(_114))) , 
or(and(x(_114) ,y(>114) ) ,neg(y (_114) ) ) ) , 
neg(cin(_114)))) , 

and(or(and(or(neg(x(_114)) ,and(x(_114) ,y(_114))) , 
or(and(x(_114) ,y(_114) ) ,neg(y(_114) ) ) ) , 
neg(cin(>114))), 
cin(>114))) 

Does  or(and(or(and(x(_114) ,or(neg(x(_U4)) ,neg(y(>114)))) , 
and(or(n«g(x(_114) ) ,neg(y(_114) ) ) ,y (>114) ) ) , 
or(and(or(neg(x(_114)) ,and(x(_114) ,y(_114))) , 
or (and(x(_114) ,y (>114) ) ,neg(y(_114) ) ) ) , 
neg(cin(_114) ) ) ) , 

and(or(and(or(neg(x(_114)),and(x(_114) ,y(_114))) , 
or(and(x(>114) ,y(>114)) ,neg(y(_114)))) , 
neg(cin(_114))) , 
cin(_114)))  =* 

xor(xor(x(_114) ,y(_114)) ,cin(>114)) 

Error  number:  83  /*  stack  space  exceeded  Error  */ 

No  error  file 
Evaluation  Aborted 
?-  halt. 


Notice  that  the  fulladder  was  unable  to  complete  on  Prolog- 1.  This  is  due  to  in¬ 
sufficient  stack  space  while  determining  the  equivalence  of  the  specified  and  derived  sum 
output.  Quintus  Prolog  had  no  such  problem  and  it  would  appear  Prolog-1  has  outlived 
its  usefulness  for  this  project. 
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